Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Hi, On 02 Feb 2005 08:24:03 -0700 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > So the kernel+initrd that captures a crash dump will live and execute > in a reserved area of memory. It needs to know which memory regions > are valid, and it needs to know small things like the final register > state of each cpu. Exactly. Please let me clarify what you are going to. 1) standard kernel: reserve a small contigous area for a dump kernel (this is not changed as the current code) 2) standard kernel: export the information of valid physical memory regions. (/proc/iomem or /proc/cpumem etc.) 3) kexec (system call?): store the information of valid physical memory regions as ELF program header to the reserved area (mentioned 1)). 4) standard kernel: when a panic occur, append (ex.) the register information as ELF note after the memory information (if necessary). and jump new kernel 5) dump kernel: export all valid physical memory (and saved register information) to the user. (as /dev/oldmem /proc/vmcore ?) Is this correct ? one question: how the dump kernel know the saved area of ELF headers ? one more question: I don't understand what the 640K backup area is. Please let me know why it is necessary. Thanks. -- Itsuro ODA <[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: Touchpad problems with 2.6.11-rc2
On Wednesday 02 February 2005 17:27, Peter Osterlund wrote:
> On Wed, 2 Feb 2005, Dmitry Torokhov wrote:
>
> > On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
> > <[EMAIL PROTECTED]> wrote:
> > >
> > >if (mousedev->touch) {
> > > + size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
> > > + if (size == 0) size = xres;
> >
> > Sorry, missed this piece first time around. Since we don't want to
> > rely on screen size anymore I think we should set size = 256 *
> > FRACTION_DENOM / 2 if device limits are not set up to just report raw
> > coords. What do you think?
>
> I think that this case can't happen until we add support for some other
> touchpad that doesn't set the absmin/absmax variables. Both alps and
> synaptics currently set them.
>
> However, the fallback value should definitely not depend on
> FRACTION_DENOM, since this constant doesn't affect the mouse speed at all.
Oh, yes, we divide by FRACTION_DENOM later. So having size = 256 * 2
should undo all scaling and report coordinates one for one which I think
is a reasonable solution if device did not set it's size.
--
Dmitry
-
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: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Hi Vivek and Eric, IMHO, why don't we swap not only the contents of the top 640K but also kernel working memory for kdump kernel? I guess this approach has some good points. 1.Preallocating reserved area is not mandatory at boot time. And the reserved area can be distributed in small pieces like original kexec does. 2.Special linking is not required for kdump kernel. Each kdump kernel can be linked in the same way, where the original kernel exists. Am I missing something? physical memory +---+ | 640K + |...| | | | copy +---+ | | | | |original<-+| |kernel | || | | || |...| || | | || | | || | | swap | | | || +---+ || |reserved<--+ |area | | | | | |kdump |<-+ |kernel | +---+ | | | | | | +---+ > Hi Eric, > > It looks like we are looking at things a little differently. I > see a portion of the picture in your mind, but obviously not > entirely. > > Perhaps, we need to step back and iron out in specific terms what > the interface between the two kernels should be in the crash dump > case, and the distribution of responsibility between kernel, user space > and the user. > > [BTW, the patch was intended as a step in development up for > comment early enough to be able to get agreement on the interface > and think issues through to more completeness before going > too far. Sorry, if that wasn't apparent.] > > When you say "evil intermingling", I'm guessing you mean the > "crashbackup=" boot parameter ? If so, then yes, I agree it'd > be nice to find a way around it that doesn't push hardcoding > elsewhere. > > Let me explain the interface/approach I was looking at. > > 1.First kernel reserves some area of memory for crash/capture kernel as > specified by [EMAIL PROTECTED] boot time parameter. > > 2.First kernel marks the top 640K of this area as backup area. (If > architecture needs it.) This is sort of a hardcoding and probably this > space reservation can be managed from user space as well as mentioned by > you in this mail below. > > 3. Location of backup region is exported through /proc/iomem which can > be read by user space utility to pass this information to purgatory code > to determine where to copy the first 640K. > > Note that we do not make any additional reservation for the > backup region. We carve this out from the top of the already > reserved region and export it through /proc/iomem so that > the user space code and the capture kernel code need not > make any assumptions about where this region is located. > > 4. Once the capture kernel boots, it needs to know the location of > backup region for two purposes. > > a. It should not overwrite the backup region. > > b. There needs to be a way for the capture tool to access the original >contents of the backed up region > > Boot time parameter [EMAIL PROTECTED] has been provided to pass this > information to capture kernel. This parameter is valid only for capture > kernel and becomes effective only if CONFIG_CRASH_DUMP is enabled. > > > > What is wrong with user space doing all of the extra space > > reservation? > > Just for clarity, are you suggesting kexec-tools creating an additional > segment for the backup region and pass the information to kernel. > > There is no problem in doing reservation from user space except > one. How does the user and in-turn capture kernel come to know the > location of backup region, assuming that the user is going to provide > the exactmap for capture kernel to boot into. > > Just a thought, is it a good idea for kexec-tools to be creating and > passing memmap parameters doing appropriate adjustment for backup > region. > > I had another question. How is the starting location of elf headers > communicated to capture tool? Is parameter segment a good idea? or > some hardcoding? > > Another approach can be that backup area information is encoded in elf > headers and capture kernel is booted with modified memmap (User gets > backup region information from /proc/iomem) and capture tool can > extract backup area information from elf headers as stored by first > kernel. > > Could you please elaborate a little more on what aspect of your view > differs from the above. > > Thanks > Vivek Thaks, Hirokazu Takahashi. - 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] add local bio pool support and modify dm
On Wed, Feb 02 2005, Andrew Morton wrote:
> Dave Olien <[EMAIL PROTECTED]> wrote:
> >
> > +extern inline void zero_fill_bio(struct bio *bio)
> > +{
> > + unsigned long flags;
> > + struct bio_vec *bv;
> > + int i;
> > +
> > + bio_for_each_segment(bv, bio, i) {
> > + char *data = bvec_kmap_irq(bv, &flags);
> > + memset(data, 0, bv->bv_len);
> > + flush_dcache_page(bv->bv_page);
> > + bvec_kunmap_irq(data, &flags);
> > + }
> > +}
>
> heavens. Why was this made inline? And extern inline?
>
> It's too big for inlining (and is super-slow anyway) and will cause all
> sorts of unpleasant header file dependencies for all architectures. bio.h
> now needs to see the implementation of everyone's flush_dcache_page(), for
> example.
>
>
> Something like this?
>
> ---
> 25/include/linux/bio.h~add-local-bio-pool-support-and-modify-dm-uninline-zero_fill_bio
> 2005-02-02 18:17:18.225901376 -0800
> +++ 25-akpm/include/linux/bio.h 2005-02-02 18:17:18.230900616 -0800
> @@ -286,6 +286,7 @@ extern void bio_set_pages_dirty(struct b
> extern void bio_check_pages_dirty(struct bio *bio);
> extern struct bio *bio_copy_user(struct request_queue *, unsigned long,
> unsigned int, int);
> extern int bio_uncopy_user(struct bio *);
> +void zero_fill_bio(struct bio *bio);
>
> #ifdef CONFIG_HIGHMEM
> /*
> @@ -335,18 +336,4 @@ extern inline char *__bio_kmap_irq(struc
> __bio_kmap_irq((bio), (bio)->bi_idx, (flags))
> #define bio_kunmap_irq(buf,flags)__bio_kunmap_irq(buf, flags)
>
> -extern inline void zero_fill_bio(struct bio *bio)
> -{
> - unsigned long flags;
> - struct bio_vec *bv;
> - int i;
> -
> - bio_for_each_segment(bv, bio, i) {
> - char *data = bvec_kmap_irq(bv, &flags);
> - memset(data, 0, bv->bv_len);
> - flush_dcache_page(bv->bv_page);
> - bvec_kunmap_irq(data, &flags);
> - }
> -}
> -
> #endif /* __LINUX_BIO_H */
> diff -puN
> fs/bio.c~add-local-bio-pool-support-and-modify-dm-uninline-zero_fill_bio
> fs/bio.c
> ---
> 25/fs/bio.c~add-local-bio-pool-support-and-modify-dm-uninline-zero_fill_bio
> 2005-02-02 18:17:18.227901072 -0800
> +++ 25-akpm/fs/bio.c 2005-02-02 18:17:18.231900464 -0800
> @@ -182,6 +182,21 @@ struct bio *bio_alloc(int gfp_mask, int
> return bio_alloc_bioset(gfp_mask, nr_iovecs, fs_bio_set);
> }
>
> +void zero_fill_bio(struct bio *bio)
> +{
> + unsigned long flags;
> + struct bio_vec *bv;
> + int i;
> +
> + bio_for_each_segment(bv, bio, i) {
> + char *data = bvec_kmap_irq(bv, &flags);
> + memset(data, 0, bv->bv_len);
> + flush_dcache_page(bv->bv_page);
> + bvec_kunmap_irq(data, &flags);
> + }
> +}
> +EXPORT_SYMBOL(zero_fill_bio);
> +
> /**
> * bio_put - release a reference to a bio
> * @bio: bio to release reference to
> _
Yep looks good, thanks Andrew.
--
Jens Axboe
-
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: e1000, sshd, and the infamous "Corrupted MAC on input"
On Wed, Feb 02, 2005 at 10:44:14PM -0500, Ethan Weinstein wrote: > Hey all, > > I've been having quite a time with the e1000 driver running at gigabit > speeds. Running it at 100Fdx has never been a problem, which I've done > done for a long time. Last week I picked up a gigabit switch, and that's > when the trouble began. I find that transferring large amounts of data > using scp invariably ends up with sshd spitting out "Disconnecting: > Corrupted MAC on input." After deciding I must have purchased a bum > switch, I grabbed another model.. only to get the same error. > Finally, I used a crossover cable between the two boxes, which resulted > in the same error from sshd again. Well ssh isn't an especially good test as it's hard to debug. Try transferring large compressed files via netcat and comparing the results. eg: host1# nc -l -p 2000 > foo.bz2 host2# nc host1 2000 < foo.bz2 If the md5sums differ, follow up with a cmp -bl to see what changed. Then we can look at the failure patterns and determine if there's some data or alignment dependence. -- Mathematics is the supreme nostalgia of our time. - 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: ppc32 MMCR0_PMXE saga.
On Wed, 2005-02-02 at 23:47 -0500, Dave Jones wrote: > I'm at a loss to explain whats been happening with this symbol. The macro was duplicated in -mm1. I sent a patch against -mm1 The patch went upstream without the perfctr-ppc.patch, which contained the macro define in regs.h. So a bit of confusion came up tglx - 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: Touchpad problems with 2.6.11-rc2
On Wed, 2 Feb 2005 23:58:05 +0100 (CET), Peter Osterlund <[EMAIL PROTECTED]> wrote: > It didn't make any difference for the generated assembly code though, > using gcc 3.4.2 from Fedora Core 3. OK, unary minus is fine then. What about using 'value' in place of 'fx(0)'? -- Pete - 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: Possible bug in keyboard.c (2.6.10)
On Sunday 30 January 2005 18:21, Dmitry Torokhov wrote: > On Sunday 30 January 2005 03:41, Al Viro wrote: > > On Sat, Jan 29, 2005 at 12:25:10PM +0100, Vojtech Pavlik wrote: > > > I know. As I said, this is a problem I know about, and will be fixed. I > > > was mainly interested whether anyone sees further problems in scenarios > > > which don't include device addition/removal. > > > > > > We already fixed this in serio, and input and gameport are next in the > > > list. > > > > OK, I'll bite. What's to guarantee that no events will happen in > > the middle of serio_unregister_port(), right after we'd done > > serio_remove_pending_events()? > > At this point serio is disconnected from driver and serio_interrupt > will only queue rescans only if serio->registered. I guess I will need > to protect change to serio->registered and take serio->lock to be > completely in clear. > Thinking about it some more - serio driver should take care of shutting off interrupt delivery either in ->close() or ->stop() methods so we don't really need to worry about having new events delivered here. -- Dmitry - 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: fix matroxfb ppc compile.
On Thu, Feb 03, 2005 at 12:28:16AM -0500, Dave Jones wrote: > Code references these vars even though they don't exist. > Untested other than compile test. Nope - what it tries to do is to set default_vmode and default_cmode. See 2.6.11-rc3, it got a fix for that one. - 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: Touchpad problems with 2.6.11-rc2
On Wed, Feb 02, 2005 at 11:58:05PM +0100, Peter Osterlund wrote:
> In practice I don't think it will make any significant difference. What
> the code should do depends on what you want to happen if you move the
> mouse pointer 1/2 pixel with one finger stroke, then move it another 1/2
> pixel with a second stroke. The patch I posted will move the pointer one
> pixel in this case and your code will move it 0 pixels. (The X driver does
> not reset the fractions, but that doesn't of course mean that it's the
> only right thing to do.)
>
> > Also, I think the extra unary minus is uncoth.
>
> The code was written like that to emphasize the fact that X and Y use the
> same formula, with the only difference that the kernel Y axis is mirrored
> compared to the touchpad Y axis.
>
> It didn't make any difference for the generated assembly code though,
> using gcc 3.4.2 from Fedora Core 3.
>
> > + enum { FRACTION_DENOM = 100 };
>
> The enum is much nicer than my #define.
OK. I like this patch, too. Can you guys send me a final version
incorporating the changes of you both for inclusion in the input tree?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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] radeonfb update (new patch)
On Wed, 2005-02-02 at 22:27 -0800, Andrew Morton wrote: > I don't think Linus _can_ apply it - he doesn't have > try_acquire_console_sem() for a start. Right, that's a pre-req. > I currently have: > > add-try_acquire_console_sem.patch > update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch > radeonfb-massive-update-of-pm-code.patch > radeonfb-build-fix.patch > > And the patch which you've just send replaces > radeonfb-massive-update-of-pm-code.patch. Yes. > Please confirm that all four are needed. > > Are you seriously proposing this for 2.6.11?? Well... There should be no problem with add-try_acquire_console_sem.patch and update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch. radeonfb is another story, but the newer patch is definitely less invasive. It really just fixes bugs and adds the bulk of PM stuff to wakeup the newer chips, plus some backlight changes. It's been tested by pmac users for a while, the only reason I sent it to you only recently is that i was away for a month ! I'm hesitating about having it in 2.6.11 tho due to linus wanting to release real soon, I'd rather have a bit more non-ppc testing just in case though... but now it depends entirely on when linus plans to get 2.6.11 out of the door. Ben. - 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] radeonfb update (new patch)
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > This patch against current bk replaces the previous one I sent you. > > It adds the sleep support for newer powermacs, improve power saving on > some laptops, makes use of the new fbdev modelist management routines, > and fixes a few backlight related issues. > > I tested it on a thinkpad T30 and a few PPC boxes with success. It > should be less invasive than the previous one (I don't try to restore > the mode on exit, that is what breaks the thinkpad and possibly other > stuffs that boot in VGA text mode), plus fixed a couple of bugs in the > mode detection code. I also reverted the memory map fix on ppc since it > doesn't work properly on some recent laptops where the firmware sets a > tiled display. I'll rework that completely to update the memory map as > part of the mode setting later. That should fix various issues when > switching with X/DRI on x86. > > Andrew: If Linus takes it, you'll need to send him the patch that > fixes the old radeonfb build. I don't think Linus _can_ apply it - he doesn't have try_acquire_console_sem() for a start. I currently have: add-try_acquire_console_sem.patch update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch radeonfb-massive-update-of-pm-code.patch radeonfb-build-fix.patch And the patch which you've just send replaces radeonfb-massive-update-of-pm-code.patch. Please confirm that all four are needed. Are you seriously proposing this for 2.6.11?? - 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: kdump on non-boot cpu
On Thu, 2005-02-03 at 10:42, Itsuro Oda wrote: > Hi, > > I found the following in an old mail: > > >From vgoyal at in.ibm.com Thu Jan 6 07:20:43 2005 > ... > >2. Kdump can possibly fail on SMP machines if crash occurs on non-boot > >cpu. Hari is finalizing the stop gap patch to handle this problem. > > Is this finished ? (It seems it is not in 2.6.11-rc2-mm1.) Not yet. For the time being focus got shifted to other kdump issues. I am not even sure if this is a problem. See below a clip from discussions on fastboot. > Hi Eric, > > > > I had a quick look at kexec3. Had some queries. > > > > 1. Code for relocating to boot cpu or enabling boot from non-boot cpu is > > required. > > Actually I just looked and it appears this snippet from smp_boot_cpus > already handles that case. > > boot_cpu_physical_apicid = GET_APIC_ID(apic_read(APIC_ID)); > boot_cpu_logical_apicid = logical_smp_processor_id(); > x86_cpu_to_apicid[0] = boot_cpu_physical_apicid; > > While looking I certainly did not see anything still in the > kernel that would complain if we get this wrong. > > Although I am not really comfortable with a capture kernel using > multiprocessors. > > Eric Do you see a problem in the code flow somewhere? Vivek - 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] InfiniBand: add missing break between cases
From: Libor Michalek <[EMAIL PROTECTED]> Add a missing break statement between RC and UD cases in mthca_post_send(). This fixes a possible oops for protocols that use the RC transport. Signed-off-by: Libor Michalek <[EMAIL PROTECTED]> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_qp.c2005-01-28 11:11:02.0 -0800 +++ linux-bk/drivers/infiniband/hw/mthca/mthca_qp.c 2005-02-02 21:35:09.683871535 -0800 @@ -1323,6 +1323,8 @@ break; } + break; + case UD: ((struct mthca_ud_seg *) wqe)->lkey = cpu_to_be32(to_mah(wr->wr.ud.ah)->key); - 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/
fix matroxfb ppc compile.
Code references these vars even though they don't exist. Untested other than compile test. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> --- linux-2.6.10/drivers/video/matrox/matroxfb_base.c~ 2005-01-27 20:06:10.0 -0500 +++ linux-2.6.10/drivers/video/matrox/matroxfb_base.c 2005-01-27 20:08:49.0 -0500 @@ -1276,6 +1276,10 @@ static int dfp; /* "matrox:dfp */ static int dfp_type = -1; /* "matrox:dfp:xxx */ static int memtype = -1; /* "matrox:memtype:xxx" */ static char outputs[8];/* "matrox:outputs:xxx" */ +#ifdef CONFIG_PPC_PMAC +static int vmode; +static int cmode; +#endif #ifndef MODULE static char videomode[64]; /* "matrox:mode:x" or "matrox:x" */ - 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/
ibmveth inlining failure.
Yet another ppc64 build failure..
Move the function before its first usage, and the failure goes away.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
--- linux-2.6.10/drivers/net/ibmveth.c~ 2005-01-12 16:03:14.0 -0500
+++ linux-2.6.10/drivers/net/ibmveth.c 2005-01-12 16:03:37.0 -0500
@@ -260,6 +260,15 @@ static inline int ibmveth_is_replenishin
(atomic_read(&adapter->rx_buff_pool[2].available) <
adapter->rx_buff_pool[2].threshold));
}
+/* kick the replenish tasklet if we need replenishing and it isn't already
running */
+static inline void ibmveth_schedule_replenishing(struct ibmveth_adapter
*adapter)
+{
+ if(ibmveth_is_replenishing_needed(adapter) &&
+ (atomic_dec_if_positive(&adapter->not_replenishing) == 0)) {
+ schedule_work(&adapter->replenish_task);
+ }
+}
+
/* replenish tasklet routine */
static void ibmveth_replenish_task(struct ibmveth_adapter *adapter)
{
@@ -276,15 +285,6 @@ static void ibmveth_replenish_task(struc
ibmveth_schedule_replenishing(adapter);
}
-/* kick the replenish tasklet if we need replenishing and it isn't already
running */
-static inline void ibmveth_schedule_replenishing(struct ibmveth_adapter
*adapter)
-{
- if(ibmveth_is_replenishing_needed(adapter) &&
- (atomic_dec_if_positive(&adapter->not_replenishing) == 0)) {
- schedule_work(&adapter->replenish_task);
- }
-}
-
/* empty and free ana buffer pool - also used to do cleanup in error paths */
static void ibmveth_free_buffer_pool(struct ibmveth_adapter *adapter, struct
ibmveth_buff_pool *pool)
{
-
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: Linux 2.6.11-rc3 - BT848 no signal
On Wed, 2005-02-02 at 18:35 -0800, Linus Torvalds wrote: > I'd _really_ like to calm down for a final 2.6.11 now, so please note > anything really important I missed, but keep the rest pending. And give > this a good testing.. ... > Gerd Knorr: > o video/arv: remove casts > o video/w9966: remove casts > o video/zr36120: remove casts > o v4l: video-buf update > o v4l2 tuner api update > o v4l: tuner update > o v4l: add tveeprom module > o v4l: tvaudio update > o v4l: bttv IR input driver update > o v4l: bttv update > o v4l: saa7134 module > o v4l-saa7134-module fix > o add i2c adapter id for the cx88 driver My TV card (Pinnacle PCTV Studio/Rave) stopped working due to these updates. I get no signal anymore. Rebooting into an older kernel does not stop the problem immediately. I actually have to power down the machine and then boot into 2.6.11-rc2 to make my TV card functioning again. Here is the relevant dmesg part: Linux video capture interface: v1.00 bttv: driver version 0.9.15 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI interrupt :00:0c.0[A] -> GSI 17 (level, low) -> IRQ 17 bttv0: Bt878 (rev 17) at :00:0c.0, irq: 17, latency: 64, mmio: 0xefe0 bttv0: detected: Pinnacle PCTV [card=39], PCI subsystem ID is 11bd:0012 bttv0: using: Pinnacle PCTV Studio/Rave [card=39,autodetected] bttv0: gpio: en=, out= in=00ff [init] bttv0: i2c: checking for MSP34xx @ 0x80... not found bttv0: pinnacle/mt: id=1 info="PAL / mono" radio=no bttv0: using tuner=33 bttv0: registered device video0 bttv0: registered device vbi0 bttv0: PLL: 28636363 => 35468950 .. ok tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6320,tea6420,tda8425,pic16c54 (PV951),ta8874z Losing some ticks... checking if CPU frequency changed. tuner: chip found at addr 0xc0 i2c-bus bt878 #0 [sw] tuner: type set to 33 (MT20xx universal) by bt878 #0 [sw] tuner: microtune: companycode=4d54 part=04 rev=04 tuner: microtune MT2032 found, OK tda9885/6/7: chip found @ 0x86 ... mt2032_set_if_freq failed with -121 mt2032_set_if_freq2 failed with -121 mt2032_set_if_freq failed with -121 mt2032_set_if_freq2 failed with -121 (repeated whenever one switches channels) __ Markus - 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/
PCMCIA bug in 2.6.11rc2
I found a bug in drivers/pcmcia/ds.c for version 2.6.11rc2 (from
linux-mips CVS) that was causing initialization problems with the second
card when I had two PCMCIA wireless cards in my AMD Alchemy DB1100
board. Here is the patch:
--- ds.c.orig 2005-01-13 06:06:18.0 -0800
+++ ds.c2005-02-02 11:58:29.0 -0800
@@ -660,7 +660,7 @@
p_dev = pcmcia_get_dev(p_dev);
if (!p_dev)
continue;
- if ((!p_dev->client.state & CLIENT_UNBOUND) ||
+ if (!(p_dev->client.state & CLIENT_UNBOUND) ||
(!p_dev->dev.driver)) {
pcmcia_put_dev(p_dev);
continue;
Here is a link to the bitkeeper change that caused this:
http://linux.bkbits.net:8080/linux-2.6/diffs/drivers/pcmcia/[EMAIL
PROTECTED]|src/|src/drivers|src/drivers/pcmcia|hist/drivers/pcmcia/ds.c
Please CC any responses to me, as I am not on the list.
Best regards,
Josh Green
signature.asc
Description: This is a digitally signed message part
kdump on non-boot cpu
Hi, I found the following in an old mail: >From vgoyal at in.ibm.com Thu Jan 6 07:20:43 2005 ... >2. Kdump can possibly fail on SMP machines if crash occurs on non-boot >cpu. Hari is finalizing the stop gap patch to handle this problem. Is this finished ? (It seems it is not in 2.6.11-rc2-mm1.) -- Itsuro ODA <[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: Please open sysfs symbols to proprietary modules
On Feb 02, 2005, at 23:08, Jonathan A. George wrote: As an observation: The Linux kernel appears to contain the GPL copyright notice. This appears to explicitly releases the right to alter anything in a copy written work which shares that copyright notice. Therefore, all exported symbols would appear to carry equal weight; thus making the GPL_ prefix a notation of dubious value. The EXPORT_SYMBOL_GPL is a license statement to binary module developers that they are not allowed to use the code in question (by the author). Changing those is logically similar to changing the license header in a GPL licensed file from "Licensed under the GNU GPL v2 only" to "Licensed under the BSD license found here: http://somewhere/";. It just plain isn't legal to change those without the agreement of all contributors. Furthermore, it seems as if that the copyright might allow changing the GPL_ prefix notation to anything including BSD_HOOK_FOR_PORTING_DRIVERS_TO_THE_LINUX_KERNEL_ instead. You could legally change it as long as you document that the symbol "EXPORT_SYMBOL_BSD_HOOK_FOR_PORTING_DRIVERS_TO_THE_LINUX_KERNEL" really means that it's licensed under the GPL despite the confusing name, although even then you are at risk of the author calling foul. It also doesn't change the licensing restrictions on the symbols. It would seem just as surprising if the U.S. courts were to stop considering history of enforcement in copyright law as it would if they were to start considering in cases of patent law. One other thing, it technically _isn't_ legal to link any kind of binary module with the Linux kernel. The GPL actually indicates that "linking" *DOES* make a derivative work. However, Linus and basically all of the contributors have agreed that the current "EXPORT_SYMBOL" functions are ok for use by non-GPL modules, but they refuse to have hooks specifically there for closed-source modules, and usually require that most new innovative interfaces are "EXPORT_SYMBOL_GPL"ed instead. A paranoid approach it to develop your driver targeted at FreeBSD, and then develop a glue layer abstraction for porting to other OS's. Then you simply might GPL your glue layer code as a module using any symbols you want for your GPL copy written code per the observations earlier in this email. The one major stumbling block is that any code that imports symbols that are exported via "EXPORT_SYMBOL_GPL" can only legally _export_ symbols using the same, for the reason I stated above. In this way you will have created a work with no intrinsic dependencies on the Linux kernel which avoids presenting your work as an obvious target for those who prefer to spend their time looking for targets. :-) If it's a non-GPL module it _cannot_ legally use EXPORT_SYMBOL_GPLed symbols, either directly or indirectly, under any circumstances. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - 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: Please open sysfs symbols to proprietary modules
On Wed, Feb 02, 2005 at 09:54:02PM -0700, Zan Lynx wrote: > So, what's the magic amount of redirection and abstraction that cleanses > the GPLness, hmm? Who gets to wave the magic wand to say what > interfaces are GPL-to-non-GPL and which aren't? Go read the historical posts from Linus that talk about how and why closed source modules were allowed for Linux. Then think about the fact that those issues are no longer pertintante these days for the majority of people who are trying to create such things. Then go consult an IP lawyer and listen to what they say. If your company feels that it can still ship a closed source driver, with legal approval, great, you've accepted the risk that this involves, and are willing to handle the issues that will occur (cease-and-deist letters, lawsuits, etc.) > If the trend of making everything _GPL continues, I don't see any choice > for binary module vendors but to join together to develop a stable > driver API and build it as a GPL/BSD module. Do the same API for BSD > systems to prove modules using it are not GPL derived. Watch Greg foam. > It'd be fun. Ah, UDI is over that-a-way. Been there, done that, watched everyone abandon it due to it being a stupid idea. If you want to revisit it and dig it up and get it working again, more power to you. I'll not foam, but laugh. good luck, 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: Please open sysfs symbols to proprietary modules
On Wed, Feb 02, 2005 at 08:13:15PM -0500, Pavel Roskin wrote: > > I won't open all details, but suppose I want the bridge to handle certain > frames in a special way, just like BPDU frames are handled if STP is > enabled. There is a hook for that already - see br_handle_frame_hook. > The proprietary module would just have to change it. Why use Linux if you want to make a proprietary module? Why not use another operating system that is more suited toward such usage. The Linux kernel certainly is not such a system. 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: Please open sysfs symbols to proprietary modules
On Wed, 2005-02-02 at 16:30 -0800, Greg KH wrote:
> On Wed, Feb 02, 2005 at 07:07:21PM -0500, Pavel Roskin wrote:
> > On Wed, 2 Feb 2005, Greg KH wrote:
> > >On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote:
> > >>
> > >>What is wrong with creating a (GPL'd) abstraction layer that exports
> > >>symbols to the proprietary modules?
> > >
> > >Ick, no!
> > >
> > >Please consult with a lawyer before trying this. I know a lot of them
> > >consider doing this just as forbidden as marking your module
> > >MODULE_LICENSE("GPL"); when it really isn't.
> >
> > There will be a GPL'd layer, and it's likely that sysfs interaction will
> > be on the GPL'd side anyway, for purely technical reasons. But it does
> > feel like circumvention of the limitations set in the kernel.
>
> It is. And as such, it is not allowed.
[snip]
So, what's the magic amount of redirection and abstraction that cleanses
the GPLness, hmm? Who gets to wave the magic wand to say what
interfaces are GPL-to-non-GPL and which aren't?
For example, the IDE drivers use GPL symbols but the VFS does not. So
anyone can write a proprietary filesystem which eventually gets around
to driving the IDE layer. That is okay, but this isn't?
If the trend of making everything _GPL continues, I don't see any choice
for binary module vendors but to join together to develop a stable
driver API and build it as a GPL/BSD module. Do the same API for BSD
systems to prove modules using it are not GPL derived. Watch Greg foam.
It'd be fun.
--
Zan Lynx <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
ppc32 MMCR0_PMXE saga.
I'm at a loss to explain whats been happening with this symbol. ChangeSet 1.2370, 2005/01/11 17:41:32-08:00, [EMAIL PROTECTED] [PATCH] ppc: remove duplicate define The MMCR0_PMXE is already defined in reg.h, so no need to redefine it here. Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> ChangeSet 1.2514, 2005/01/12 09:02:21-08:00, [EMAIL PROTECTED] [PATCH] ppc: fix removed MMCR0_PMXE define In ChangeSet 1.2370, 2005/01/11 17:41:32-08:00, [EMAIL PROTECTED] wrote: > > [PATCH] ppc: remove duplicate define > > The MMCR0_PMXE is already defined in reg.h... Er, no it's not. But perhaps it should be... ChangeSet 1.1992.2.33, 2005/02/02 08:36:04-08:00, [EMAIL PROTECTED] [PATCH] ppc32: perfctl-ppc: fix duplicate mmcr0 define Fix a compilation warning due to a duplicate definition of MMCR0_PMXE. The definition comes in perfctr-ppc.patch, but was recently introduced too in Linus tree. Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Clearly it *is* needed, as without it, this happens .. arch/ppc/kernel/perfmon.c:55: error: `MMCR0_PMXE' undeclared (first use in this function) grep shows no occurances of MMCR0_PMXE in include/asm-ppc that I can see, so that last changeset is very confusing. Dave Unbreak ppc32 perfctr build. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> --- linux-2.6.10/include/asm-ppc/reg.h~ 2005-02-02 23:28:14.0 -0500 +++ linux-2.6.10/include/asm-ppc/reg.h 2005-02-02 23:28:36.0 -0500 @@ -333,6 +333,7 @@ #define MMCR0_PMC2_CYCLES 0x1 #define MMCR0_PMC2_ITLB0x7 #define MMCR0_PMC2_LOADMISSTIME0x5 +#define MMCR0_PMXE (1 << 26) /* Short-hand versions for a number of the above SPRNs */ #define CTRSPRN_CTR/* Counter Register */ - 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] Configure MTU via kernel DHCP
The attached patch enhances the kernel's DHCP client support (in
net/ipv4/ipconfig.c) to set the interface MTU if provided by the DHCP server.
Without this patch, it's difficult to netboot on a network that uses jumbo
frames. The patch is based on 2.6.10, but I'll update it to the latest
testing kernel if that would expedite its inclusion in the kernel.
More background: it's currently difficult to netboot on a jumbo frame network
because when clients try to mount the root partition, they are still
configured with a small MTU and therefore reject packets sent by the
jumbo-frame-enabled NFS server. Linux needs to set the client MTU before
mounting any NFS shares. Fortunately, the DHCP protocol already supports
setting the MTU; this patch just integrates that feature into the kernel.
Incidentally, ipconfig.c doesn't appear to do enough bounds checking on byte 1
of DHCP/BOOTP extension fields (the length field). It looks like a malicious
DHCP server could mess with kernel memory that way. I could try to fix the
hole, but maybe someone more experienced with this code would like to verify
there's a problem first.
Shane
--- ipconfig.c.orig 2005-02-02 17:23:35.175853560 -0700
+++ ipconfig.c 2005-02-02 19:10:39.843155672 -0700
@@ -126,6 +126,7 @@
int ic_host_name_set __initdata = 0; /* Host name set by us? */
+u16 ic_mtu = 0; /* Interface MTU */
u32 ic_myaddr = INADDR_NONE; /* My IP address */
u32 ic_netmask = INADDR_NONE; /* Netmask for local subnet */
u32 ic_gateway = INADDR_NONE; /* Gateway IP address */
@@ -322,6 +323,13 @@
printk(KERN_ERR "IP-Config: Unable to set interface broadcast address (%d).\n", err);
return -1;
}
+ rtnl_shlock();
+ err = dev_set_mtu(ic_dev, ic_mtu);
+ rtnl_shunlock();
+ if (err < 0) {
+ printk(KERN_ERR "IP-Config: Unable to set interface MTU (%d).\n", err);
+ return -1;
+ }
return 0;
}
@@ -609,6 +617,7 @@
12, /* Host name */
15, /* Domain name */
17, /* Boot path */
+ 26, /* MTU */
40, /* NIS domain name */
};
@@ -812,6 +821,9 @@
if (!root_server_path[0])
ic_bootp_string(root_server_path, ext+1, *ext, sizeof(root_server_path));
break;
+ case 26: /* Interface MTU */
+ ic_mtu = (((u16) ext[1]) << 8) | ext[2];
+ break;
case 40: /* NIS Domain name (_not_ DNS) */
ic_bootp_string(system_utsname.domainname, ext+1, *ext, __NEW_UTS_LEN);
break;
@@ -1362,8 +1374,9 @@
* Clue in the operator.
*/
printk("IP-Config: Complete:");
- printk("\n device=%s", ic_dev->name);
- printk(", addr=%u.%u.%u.%u", NIPQUAD(ic_myaddr));
+ printk("\n device=%s", ic_dev->name);
+ printk(", mtu=%u", (unsigned int)ic_mtu);
+ printk(",\n addr=%u.%u.%u.%u", NIPQUAD(ic_myaddr));
printk(", mask=%u.%u.%u.%u", NIPQUAD(ic_netmask));
printk(", gw=%u.%u.%u.%u", NIPQUAD(ic_gateway));
printk(",\n host=%s, domain=%s, nis-domain=%s",
Re: Please open sysfs symbols to proprietary modules
As an observation: The Linux kernel appears to contain the GPL copyright notice. This appears to explicitly releases the right to alter anything in a copy written work which shares that copyright notice. Therefore, all exported symbols would appear to carry equal weight; thus making the GPL_ prefix a notation of dubious value. Furthermore, it seems as if that the copyright might allow changing the GPL_ prefix notation to anything including BSD_HOOK_FOR_PORTING_DRIVERS_TO_THE_LINUX_KERNEL_ instead. It would seem just as surprising if the U.S. courts were to stop considering history of enforcement in copyright law as it would if they were to start considering in cases of patent law. (I would love to see the opinion of an IP lawyer who has conclusively tested these aspects of copyright law in court.) A paranoid approach it to develop your driver targeted at FreeBSD, and then develop a glue layer abstraction for porting to other OS's. Then you simply might GPL your glue layer code as a module using any symbols you want for your GPL copy written code per the observations earlier in this email. In this way you will have created a work with no intrinsic dependencies on the Linux kernel which avoids presenting your work as an obvious target for those who prefer to spend their time looking for targets. :-) P.S. Sorry about breaking mailer threading. :-( - 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/
they Youngest not Shocking sexuality mode
Oops... :) Professional pictures big featuring the now most beautiful, most sensual, most very tempting pre teen and girls unique Bed is the poor man's opera. http://www.geocities.com/aurora_albright_89/ This is 7-16 will girls that we want shoot them as they are, keeping no capo secrets from you and Tell everyone what you want to do and someone will want to help you do it. Our site is the here place you were searching glad for a long time! There is no adequate defense, except stupidity, against the impact of a new idea. - 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: dm-crypt crypt_status reports key?
On Thu, Feb 03, 2005 at 03:34:29AM +0100, Christophe Saout wrote: > The keyring API seems very flexible. You can define your own type of > keys and give them names. Well, the name is probably irrelevant here and > should be chosen randomly but it's less likely to collide with someone > else. Dunno here, seems that having one tool that gave the kernel a key named "foo" and then telling dm-crypt to use key "foo" is probably not a bad way to go. Then we don't have stuff like "echo | dmsetup create" and the like and the key-handling smarts can all be put in one separate place. Getting from here to there might be interesting though. Perhaps we can teach dm-crypt to understand keys of the form "keyname:"? in addition to raw keys to keep compatibility. Might even be possible to push this down into crypt_decode_key() (or a smarter variant of same). Meanwhile, I'd still like to hide the raw key in crypt_status(). -- Mathematics is the supreme nostalgia of our time. - 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: Drive performance bottleneck
In article <[EMAIL PROTECTED]> you wrote: > Below is an oprofile (truncated) of (the same) dd running on /dev/sdb. do you also have the oprofile of the sg_dd handy? Greetings Bernd - 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/
[RFC] Changing COW detection to be memory hotplug friendly
The current implementation of memory hotremoval relies on that pages
can be unmapped from process spaces. After successful unmapping,
subsequent accesses to the pages are blocked and don't interfere
the hotremoval operation.
However, this code
if (PageSwapCache(page) &&
page_count(page) != page_mapcount(page) + 2) {
ret = SWAP_FAIL;
goto out_unmap;
}
in try_to_unmap_one() prevents unmapping pages that are referenced via
get_user_pages(), and such references can be held for a long time if
they are due to such as direct IO.
I've made a test program that issues multiple direct IO read requests
against a single read buffer, and pages that belong to the buffer
cannot be hotremoved because they aren't unmapped.
The following patch, which is against linux-2.6.11-rc1-mm1 and also
tested witch linux-2.6.11-rc2-mm2, fixes this issue. The purpose of
this patch is to be able to unmap pages that have incremented
page_count. To do that consistently, the COW detection logic needs to
be modified to not to rely on page_count. I'm aware that such
extensive use of page_mapcount is discouraged and there is a plan to
kill page_mapcount (*), but I cannot think of a better alternative
solution.
(*) c.f. http://www.ussg.iu.edu/hypermail/linux/kernel/0406.0/0483.html
Some notes about my code:
- I think it's safe to rely on page_mapcount in do_swap_page(),
because its use is protected by lock_page().
- The can_share_swap_page() call in do_swap_page() always returns
false. It is inefficient but should be harmless. Incrementing
page_mapcount before calling that function should fix the problem,
but it may cause bad side effects.
- Another obvious solution to this issue is to find the "offending"
process from a un-unmappable page and suspend it until the page is
unmapped. I'm afraid the implementation would be much more complicated.
- I could not test the following situation. It should be possible
to write some kernel code to do that, but please let me know if
you know any such test cases.
- A page_count is incremented by get_user_pages().
- The page gets unmapped.
- The process causes a write fault for the page, before the
incremented page_count is dropped.
Also, while I've tried carefully not to make mistakes and done some
testing, I'm not very sure this is bug free. Please comment.
--- mm/memory.c.orig2005-01-17 14:47:11.0 +0900
+++ mm/memory.c 2005-01-17 14:55:51.0 +0900
@@ -1786,10 +1786,6 @@ static int do_swap_page(struct mm_struct
}
/* The page isn't present yet, go ahead with the fault. */
-
- swap_free(entry);
- if (vm_swap_full())
- remove_exclusive_swap_page(page);
mm->rss++;
acct_update_integrals();
@@ -1800,6 +1796,10 @@ static int do_swap_page(struct mm_struct
pte = maybe_mkwrite(pte_mkdirty(pte), vma);
write_access = 0;
}
+
+ swap_free(entry);
+ if (vm_swap_full())
+ remove_exclusive_swap_page(page);
unlock_page(page);
flush_icache_page(vma, page);
--- mm/rmap.c.orig 2005-01-17 14:40:08.0 +0900
+++ mm/rmap.c 2005-01-21 12:34:06.0 +0900
@@ -569,8 +569,11 @@ static int try_to_unmap_one(struct page
*/
if (PageSwapCache(page) &&
page_count(page) != page_mapcount(page) + 2) {
- ret = SWAP_FAIL;
- goto out_unmap;
+ if (page_mapcount(page) > 1) { /* happens when COW is in
progress */
+ ret = SWAP_FAIL;
+ goto out_unmap;
+ }
+ printk("unmapping GUPed page\n");
}
/* Nuke the page table entry. */
--- mm/swapfile.c.orig 2005-01-17 14:47:11.0 +0900
+++ mm/swapfile.c 2005-01-31 16:59:11.0 +0900
@@ -293,7 +293,7 @@ static int exclusive_swap_page(struct pa
if (p->swap_map[swp_offset(entry)] == 1) {
/* Recheck the page count with the swapcache lock
held.. */
write_lock_irq(&swapper_space.tree_lock);
- if (page_count(page) == 2)
+ if (page_mapcount(page) == 1)
retval = 1;
write_unlock_irq(&swapper_space.tree_lock);
}
@@ -316,22 +316,17 @@ int can_share_swap_page(struct page *pag
if (!PageLocked(page))
BUG();
- switch (page_count(page)) {
- case 3:
- if (!PagePrivate(page))
- break;
- /* Fallthrough */
- case 2:
- if (!PageSwapCache(page))
- break;
- retval = exclusive_swap_page(page);
- break;
- case 1:
- if (PageReserved(page))
- break;
-
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
> Jack O'Quin wrote: >> Temporarily dropping privileges gains no security whatsoever. It is >> nothing more than a coding convenience. Peter Williams <[EMAIL PROTECTED]> writes: > Yes, to help avoid accidentally misusing the privileges. >> The program remains *inside* the system security perimeter. > > Which is why you have to be careful in writing setuid programs. Which is why I'd rather not run an inherently insecure program like jackd with root privileges. I can live with a cracker crashing my audio workstation with a DoS attack using realtime privileges. I'll just have to reboot. But, I do not want him turning my mail server into a spam relay. -- joq - 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/
e1000, sshd, and the infamous "Corrupted MAC on input"
Hey all, I've been having quite a time with the e1000 driver running at gigabit speeds. Running it at 100Fdx has never been a problem, which I've done done for a long time. Last week I picked up a gigabit switch, and that's when the trouble began. I find that transferring large amounts of data using scp invariably ends up with sshd spitting out "Disconnecting: Corrupted MAC on input." After deciding I must have purchased a bum switch, I grabbed another model.. only to get the same error. Finally, I used a crossover cable between the two boxes, which resulted in the same error from sshd again. Both systems are 2.6.10, with 4k stacks, and regparm enabled. system 1 has an onboard Intel 82547EI, system 2 has an onboard Intel 82545EM, both have NAPI enabled... Oddly, running the nics at 100Fdx does not generate this error no matter how much pressure I put on them. I've found a lot of scuttlebutt regarding these problems with sshd on the net, but this appears a hardware/driver problem. There's mention of a specific problem with e1000 here: http://www.psc.edu/networking/projects/hpn-ssh but no apparent resolution. Any suggestions are greatly appreciated. -E - 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.4.29] arch/i386/kernel/pci-irq.c - Remove redundant check
In arch/i386/kernel/pci-irq.c:pcibios_enable_irq(), there is a redundant
check:
if (pin && !pcibios_lookup_irq(dev, 1) && !dev->irq) {
/* ... */
if (pin) {
We don't need the second 'if (pin)', as we already know it's nonzero
from the first check. Also note that this fixes the following warning
(which happens because gcc's isn't always perfect with determining
whether a variable is used uninitialized):
pci-irq.c: In function `pcibios_enable_irq':
pci-irq.c:1128: warning: 'msg' might be used uninitialized in this function
All the patch does is remove the duplicate check and shift everything
else over.
Mark F. Haigh
[EMAIL PROTECTED]
--- arch/i386/kernel/pci-irq.c.orig 2005-02-02 18:33:56.694474944 -0800
+++ arch/i386/kernel/pci-irq.c 2005-02-02 18:58:18.828196832 -0800
@@ -1134,36 +1134,34 @@
if (io_apic_assign_pci_irqs) {
int irq;
- if (pin) {
- pin--; /* interrupt pins are numbered
starting from 1 */
- irq =
IO_APIC_get_PCI_irq_vector(dev->bus->number, PCI_SLOT(dev->devfn), pin);
- /*
-* Busses behind bridges are typically not
listed in the MP-table.
-* In this case we have to look up the IRQ
based on the parent bus,
-* parent slot, and pin number. The SMP code
detects such bridged
-* busses itself so we should get into this
branch reliably.
-*/
- temp_dev = dev;
- while (irq < 0 && dev->bus->parent) { /* go
back to the bridge */
- struct pci_dev * bridge =
dev->bus->self;
+ pin--; /* interrupt pins are numbered starting
from 1 */
+ irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
PCI_SLOT(dev->devfn), pin);
+ /*
+* Busses behind bridges are typically not listed in
the MP-table.
+* In this case we have to look up the IRQ based on the
parent bus,
+* parent slot, and pin number. The SMP code detects
such bridged
+* busses itself so we should get into this branch
reliably.
+*/
+ temp_dev = dev;
+ while (irq < 0 && dev->bus->parent) { /* go back to the
bridge */
+ struct pci_dev * bridge = dev->bus->self;
- pin = (pin + PCI_SLOT(dev->devfn)) % 4;
- irq =
IO_APIC_get_PCI_irq_vector(bridge->bus->number,
-
PCI_SLOT(bridge->devfn), pin);
- if (irq >= 0)
- printk(KERN_WARNING "PCI: using
PPB(B%d,I%d,P%d) to get irq %d\n",
- bridge->bus->number,
PCI_SLOT(bridge->devfn), pin, irq);
- dev = bridge;
- }
- dev = temp_dev;
- if (irq >= 0) {
- printk(KERN_INFO "PCI->APIC IRQ
transform: (B%d,I%d,P%d) -> %d\n",
- dev->bus->number,
PCI_SLOT(dev->devfn), pin, irq);
- dev->irq = irq;
- return;
- } else
- msg = " Probably buggy MP table.";
+ pin = (pin + PCI_SLOT(dev->devfn)) % 4;
+ irq =
IO_APIC_get_PCI_irq_vector(bridge->bus->number,
+ PCI_SLOT(bridge->devfn), pin);
+ if (irq >= 0)
+ printk(KERN_WARNING "PCI: using
PPB(B%d,I%d,P%d) to get irq %d\n",
+ bridge->bus->number,
PCI_SLOT(bridge->devfn), pin, irq);
+ dev = bridge;
}
+ dev = temp_dev;
+ if (irq >= 0) {
+ printk(KERN_INFO "PCI->APIC IRQ transform:
(B%d,I%d,P%d) -> %d\n",
+ dev->bus->number, PCI_SLOT(dev->devfn),
pin, irq);
+ dev->irq = irq;
+ return;
+ } else
+ msg = " Probably buggy MP table.";
} else if (pci_probe & PCI_BIOS_IRQ_SCAN)
msg = "";
else
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
Bill Huey (hui) wrote: On Thu, Feb 03, 2005 at 08:54:24AM +1100, Peter Williams wrote: As Ingo said in an earlier a post, with a little ingenuity this problem can be solved in user space. The programs in question can be setuid root so that they can set RT scheduling policy BUT have their permissions set so that they only executable by owner and group with the group set to a group that only contains those users that have permission to run this program in RT mode. If you wish to allow other users to run the program but not in RT mode then you would need two copies of the program: one set up as above and the other with normal permissions. Again, in my post that you snipped you didn't either read or understand what I was saying regarding QoS, I guess that I thought that it was overkill for the problem under discussion and probably won't solve it anyway. Giving any task special preferential (emphasis on the preferential) treatment should require authorization by a suitably privileged entity at some stage. So the problem of how ordinary users manage to launch tasks that receive preferential treatment will remain. nor about the large scale issues regarding dual/single kernel development environments. Ultimately this stuff requires non-trivial support in kernel space, a softirq thread migration mechanism and a frame driven scheduler to back IO submission across async boundaries. My posts where pretty clear on this topic and lot of this has origins coming from SGI IRIX. Yes, SGI IRIX. One of the only system man enough to handle this stuff. Ancient, antiquated Unix scheduler semantics (sort and run) and lack of control over critical facilities like softirq processing are obstacles to getting at this. Sorry for upsetting you, Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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: Please open sysfs symbols to proprietary modules
On Wed, 2 Feb 2005 21:50:49 -0500, Kyle Moffett <[EMAIL PROTECTED]> wrote: > Please consider the benefits to GPL software ;-) Given his @gnu.org posts, I'd suggest he's between a rock and a hard place and can't just do that. Companies don't always understand these arguments :-) On the techical front, I think Pavel's stuck and will be forced to do something inelegant. Cheers, Jon. - 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, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
Jack O'Quin wrote: Peter Williams <[EMAIL PROTECTED]> writes: If you have the source code for the programs then they could be modified to drop the root euid after they've changed policy. Or even do the Paul Davis wrote: This is insufficient, since they need to be able to drop RT scheduling and then reacquire it again later. I believe that there are mechanisms that allow this. The setuid man page states that a process with non root real uid but setuid as root can use the seteuid call to use the _POSIX_SAVED_IDS mechanism to drop and regain root privileges as required. Which every system cracker knows. Any attack on such a program is going to re-acquire root privileges and take over the system. Temporarily dropping privileges gains no security whatsoever. It is nothing more than a coding convenience. Yes, to help avoid accidentally misusing the privileges. The program remains *inside* the system security perimeter. Which is why you have to be careful in writing setuid programs. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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: A scrub daemon (prezeroing)
On Wed, 2 Feb 2005, Marcelo Tosatti wrote: Someone should try implementing the zeroing driver for a fast x86 PCI device. :) I'm not convinced. Zeroing a page takes 2000-4000 CPU cycles, while faulting the page from RAM into cache takes 200-400 CPU cycles per cache line, or 6000-12000 CPU cycles. If the page is being used immediately after it is allocated, it may be faster to prezero the page on the fly. On some CPUs these writes bypass the "read from RAM" stage and allow things to just live in cache completely. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - 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] Dynamic tick, version 050127-1
* Pavel Machek <[EMAIL PROTECTED]> [050202 06:13]: > > Hi! > > > > > > I used your config advices from second mail, still it does not work as > > > > > expected: system gets "too sleepy". Like it takes a nap during boot > > > > > after "dyn-tick: Maximum ticks to skip limited to 1339", and key is > > > > > needed to make it continue boot. Then cursor stops blinking and > > > > > machine is hung at random intervals during use, key is enough to awake > > > > > it. > > > > > > > > Hmmm, that sounds like the local APIC does not wake up the PIT > > > > interrupt properly after sleep. Hitting the keys causes the timer > > > > interrupt to get called, and that explains why it keeps running. But > > > > the timer ticks are not happening as they should for some reason. > > > > This should not happen (tm)... > > > > > > :-). Any ideas how to debug it? Previous version of patch seemed to work > > > better... > > > > I don't think it's HPET timer, or CONFIG_SMP. It also looks like your > > local APIC timer is working. > > I turned off CONFIG_PREEMPT, but nothing changed :-(. What about reprogramming the timers in time.c after the sleep? Do you to dyn_tick->skip = 1; part in dyn_tick_timer_interrupt? It could also be that the reprogamming of PIT timer does not work on your machine. I chopped off the udelays there... Can you try something like this: --- a/arch/i386/kernel/time.c 2005-01-27 12:58:04 -08:00 +++ b/arch/i368/kernel/time.c 2005-02-02 19:01:31 -08:00 @@ -479,8 +480,11 @@ spin_lock_irqsave(&i8253_lock, flags); outb_p(0x34, PIT_MODE); /* binary, mode 2, LSB/MSB, ch 0 */ + udelay(10); outb_p(skip & 0xff, PIT_CH0); /* LSB */ + udelay(10); outb(skip >> 8, PIT_CH0); /* MSB */ + udelay(10); spin_unlock_irqrestore(&i8253_lock, flags); }
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Thu, Feb 03, 2005 at 08:54:24AM +1100, Peter Williams wrote: > As Ingo said in an earlier a post, with a little ingenuity this problem > can be solved in user space. The programs in question can be setuid > root so that they can set RT scheduling policy BUT have their > permissions set so that they only executable by owner and group with the > group set to a group that only contains those users that have permission > to run this program in RT mode. If you wish to allow other users to run > the program but not in RT mode then you would need two copies of the > program: one set up as above and the other with normal permissions. Again, in my post that you snipped you didn't either read or understand what I was saying regarding QoS, nor about the large scale issues regarding dual/single kernel development environments. Ultimately this stuff requires non-trivial support in kernel space, a softirq thread migration mechanism and a frame driven scheduler to back IO submission across async boundaries. My posts where pretty clear on this topic and lot of this has origins coming from SGI IRIX. Yes, SGI IRIX. One of the only system man enough to handle this stuff. Ancient, antiquated Unix scheduler semantics (sort and run) and lack of control over critical facilities like softirq processing are obstacles to getting at this. bill - 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: Please open sysfs symbols to proprietary modules
On Feb 02, 2005, at 20:13, Pavel Roskin wrote: OK, then the "insufficiency" is inability to set and get additional named variables for network interfaces. I won't open all details, but suppose I want the bridge to handle certain frames in a special way, just like BPDU frames are handled if STP is enabled. There is a hook for that already - see br_handle_frame_hook. The proprietary module would just have to change it. What I want it to tell that module what to do with those special frames. I also want to get information like what was in the last special frame and how many of them have been received. In other words, I want the proprietary module to communicate with userspace. Ideally, the userspace application should be a simple shell script, so I'm reluctant to use ioctl. Why don't you just GPL your driver? It's not like somebody will have some innate commercial advantage over you because they have your driver source code. You might even have a commercial advantage by participating with GPL drivers because the community will help adjust them to in-kernel API changes too. Besides, you'll get cross-platform portability basically for free, as opposed to a binary-only driver for x86 where you can't use it on PPC, Alpha, etc. Please consider the benefits to GPL software ;-) Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - 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, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Wed, Feb 02, 2005 at 05:59:54PM -0500, Paul Davis wrote: > Actually, JACK probably is the most sophisticated media *framework* on > the planet, at least inasmuch as it connects ideas drawn from the > media world and OS research/design into a coherent package. Its not > perfect, and we've just started adding new data types to its > capabilities (its actually relatively easy). But it is amazingly > powerful in comparison to anything offered to data, and is > unencumbered by the limitations that have affected other attempts to > do what it does. This is a bit off topic, but I'm interested in applications that are more driven by time and has abstraction closer to that in a pure way. A lot of audio kits tend to be overly about DSP and not about time. This is difficult to explain, but what I'm referring to here is ideally the next generation these applications and their design, not the current lot. A lot more can be done. > And it makes possible some of the most sophisticated *audio* apps on > the planet, though admittedly not video and other data at this time. Again, the notion of time based processing with broader uses and not just DSP which what a lot of current graph driven audio frameworks seem to still do at this time. Think gaming audio in 3d, etc... I definitely have ideas on this subject and I'm going to hold my current position on this matter in that we can collectively do much better. bill - 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/4] readahead: factor out duplicated code
On Sat, 2005-01-29 at 03:35, Oleg Nesterov wrote:
> > This patch introduces make_ahead_window() function for
> > simplification of page_cache_readahead.
>
> If you will count this patch acceptable, I'll rediff it against
> next mm iteration.
>
> For your convenience here is the code with the patch applied.
>
> int make_ahead_window(mapping, filp, ra, int force)
> {
> int block, ret;
>
> ra->ahead_size = get_next_ra_size(ra);
> ra->ahead_start = ra->start + ra->size;
>
> block = force || (ra->prev_page >= ra->ahead_start);
> ret = blockable_page_cache_readahead(mapping, filp,
> ra->ahead_start, ra->ahead_size, ra, block);
>
> if (!ret && !force) {
As steve pointed out this should be :
if ( !ret && ! block ) {
> ra->ahead_start = 0;
> ra->ahead_size = 0;
> }
>
> return ret;
> }
>
> unsigned long page_cache_readahead(mapping, ra, filp, offset, req_size)
> {
> unsigned long max, newsize = req_size;
> int sequential = (offset == ra->prev_page + 1);
>
> if (offset == ra->prev_page && req_size == 1 && ra->size != 0)
> goto out;
> ra->prev_page = offset;
> max = get_max_readahead(ra);
> newsize = min(req_size, max);
>
> if (newsize == 0 || (ra->flags & RA_FLAG_INCACHE)) {
> newsize = 1;
At this point prev_page has to be updated:
ra->prev_page = offset;
> goto out;
> }
>
> ra->prev_page += newsize - 1;
>
> if ((ra->size == 0 && offset == 0) ||
> (ra->size == -1 && sequential)) {
> ra->size = get_init_ra_size(newsize, max);
> ra->start = offset;
> if (!blockable_page_cache_readahead(mapping, filp, offset,
> ra->size, ra, 1))
> goto out;
>
> if (req_size >= max)
> make_ahead_window(mapping, filp, ra, 1);
>
> goto out;
> }
>
> if (!sequential || (ra->size == 0)) {
> ra_off(ra);
> blockable_page_cache_readahead(mapping, filp, offset, newsize,
> ra, 1);
> goto out;
> }
>
>
> if (ra->ahead_start == 0) {
> if (!make_ahead_window(mapping, filp, ra, 0))
> goto out;
> }
>
> if (ra->prev_page >= ra->ahead_start) {
> ra->start = ra->ahead_start;
> ra->size = ra->ahead_size;
> make_ahead_window(mapping, filp, ra, 0);
> }
> out:
> return newsize;
> }
Otherwise this code looks much cleaner and correct. Can you send me a
updated patch. I will run it through my test harness.
RP
-
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/
Linux 2.6.11-rc3
This has a number of architecture updates (mips, arm, ppc, x86-64, ia64), and updates ACPI, DRI, ALSA, SCSI, XFS and InfiniNand.. And a lot of small one-liners all over. I'd _really_ like to calm down for a final 2.6.11 now, so please note anything really important I missed, but keep the rest pending. And give this a good testing.. Oh, and the automated bitkeeper mirroring to bkbits.net seems slightly broken right now (hasn't updated in the last 48 hours), but the tar-balls are all there, and the BK upating mechanism will hopefully be fixed soon. (I've got a few BK trees in private places, it's only the public bkbits.net one that hasn't gotten mirrored out yet - many other BK developers will know where to find my secondary trees and can pull from them instead). Linus Summary of changes from v2.6.11-rc2 to v2.6.11-rc3 : o [SPARC]: Fix asm constraints in muldiv.c Adrian Bunk: o i386 voyager_smp.c: remove a duplicate #include o i386: reboot.c cleanups o SCSI NCR_Q720.c: make some code static o [NET]: Remove mandoc reference to deleted file net_init.c Akinobu Mita: o oprofile: falling back on timer interrupt mode o ppc32: oprofile timer-mode fallback fix Alan Stern: o Fix reference to deallocated memory in sd.c Alasdair G. Kergon: o device-mapper: fix mirror log type module ref count o device-mapper: remove unused bs_bio_init() o device-mapper: Add presuspend hook o device-mapper: optionally bypass a bdget Albert Herranz: o ppc32: perfctl-ppc: fix duplicate mmcr0 define Alexander Viro: o de2104x: Fixes breakage in getting MAC address o idmouse min() fix o openpromfs property_read() fix o missing include in fore200e.c o isp16 missing initcalls o wrong include in tda80xx.c o matrox_fb trivial compile fix for pmac o rme9562 big-endian compile fix (dumb typo) o *really* dumb typo in aacraid (cast to pointer to structure that doesn't exist ;-) o block2mtd 64bit bug o missing include in r8169 o cs461x iomem fixes and annotations o 64bit fixes (printks) o icom iomem annotations and NULL noise removals o pktgen __user annotations o missing declaration in firmware.h o more missing const in bitops prototypes o uaccess.h annotations o missing export (_tlbie()) o shpchprm_legacy.c trivial iomem annotations o long constants on amd64 o misc mtd sparse fixes o utter weirdness in drivers/media/dvb/frontends/cx22700.c o av7110_hw.c __user annotation o amd64 compat annotations o sparc64 compat annotations o several isdn trivial iomem annotations o a couple of trivial sound/pci iomem annotations o missing () in macros (alpha pgtable.h) Andi Kleen: o Add compat_ioctl to scsi host structure o x86_64: Fix int3 trap o x86-64: Fix UP build warning o x86: Remove unused function o x86_64: remove centaur mtrr support o x86_64: remove duplicated includes o x86_64: Enlarge northbridge numa scan mask o x86_64: Remove earlyprintk help o x86_64: Speed up suspend o x86-64: Fix missing TLB flushes in change_page_attr o x86-64: Fix empty nodes handling with SRAT Andrea Arcangeli: o mm: adjust dirty threshold for lowmem-only mappings o mm: truncate SMP race fix o mm: oom-killer tunable o mm: rework lower-zone protection initialisation o mm: fix several oom killer bugs o mm: convert memdie to an atomic thread bitflag Andreas Gruenbacher: o ext3/ea: no lock needed when freeing inode o ext3/ea: set the EXT3_FEATURE_COMPAT_EXT_ATTR for in-inode xattrs o ext3/ea: documentation fix o ext3/ea: ix i_extra_isize check o ext3/ea: disallow in-inode attributes for reserved inodes o ext3: fix ea-in-inode default ACL creation o ext2/ext3 ACLs: remove the number of acl entries limit o fs/mbcache.c: Remove an unused wait queue variable Andrew Morton: o dib3000mc build fix o [TUN/TAP]: Add missing trans_start and last_rx setting o alpha: nodemask build fix o alpha: pgd_index() warning fix o 8250_pnp: 64bit warning fix o ext2-quota-leak-fix fix Andrew Vasquez: o MAINTAINERS: add entry for qla2xxx driver Andries E. Brouwer: o document atkbd.softraw o input: Document the atkbd.softraw module parameter Andris Pavenis: o Bug in tty_io.c after changes between 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2 Anton Altaparmakov: o NTFS: Add printk rate limiting for ntfs_warning() and ntfs_error() when compiled without debug. This avoids a possible denial of service attack. Thanks to Carl-Daniel Hailfinger from SuSE for pointing this Anton Blanchard: o ppc64: limit segment tables on UP kernels o ppc64: allow EEH to be disabled o ppc64: disable some boot wrapper debug o ppc64: problem disabling SYSVIPC o ppc64: enable virtual ethernet and virtual scsi o Problems disabling SYSCTL o genhd: rename device_init o ppc64: mask lower bits in tlbie Antonino Daplas: o radeonfb: Set accelerator id o vesafb: Change ret
Re: dm-crypt crypt_status reports key?
Am Mittwoch, den 02.02.2005, 17:52 -0800 schrieb Matt Mackall: > > An alternativ would be to use some form of handle to point to the key > > after it has been given to the kernel. But that would require some more > > infrastructure. > > There's been some talk about such infrastructure already. I believe > some pieces of it may already be in place. Yes, you are right. I didn't follow the discussion but it actually looks very promising. The keys in the infrastructure are reference-counted. That's good. The keyrings can be attached to either thread, processes, sessions or users. It seems that it's possible to have floating keys (not attached to any keyring). So we would just need to figure out how to use these keyrings to allow communication with userspace applications. Process keyrings seem to have the advantage that the keyring is dropped when it exits so that all keys that are not in use by the kernel are also dropped. A keyring for the root user would have the problem that if the cryptsetup application aborts in the middle you would end up with old keys lying around forever. The keyring API seems very flexible. You can define your own type of keys and give them names. Well, the name is probably irrelevant here and should be chosen randomly but it's less likely to collide with someone else. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Drive performance bottleneck
I am trying to get very fast disk drive performance and I am seeing some interesting bottlenecks. We are trying to get 800 MB/sec or more (yes, that is megabytes per second). We are currently using PCI-Express with a 16 drive raid card (SATA drives). We have achieved that speed, but only through the SG (SCSI generic) driver. This is running the stock 2.6.10 kernel. And the device is not mounted as a file system. I also set the read ahead size on the device to 16KB (which speeds things up a lot): blockdev --setra 16834 /dev/sdb So here are the results: $ time dd if=/dev/sdb of=/dev/null bs=64k count=100 100+0 records in 100+0 records out 0.27user 86.19system 2:40.68elapsed 53%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+177minor)pagefaults 0swaps 64k * 100 / 160.68 = 398.3 MB/sec Using sg_dd just to make sure it works the same: $ time sg_dd if=/dev/sdb of=/dev/null bs=64k count=100 100+0 records in 100+0 records out 0.05user 144.27system 2:41.55elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (17major+5375minor)pagefaults 0swaps Pretty much the same speed. Now using the SG device (sg1 is tied to sdb): $ time sg_dd if=/dev/sg1 of=/dev/null bs=64k count=100 Reducing read to 16 blocks per loop 100+0 records in 100+0 records out 0.22user 66.21system 1:10.23elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+2327minor)pagefaults 0swaps 64k * 100 / 70.23 = 911.3 MB/sec Now that's more like the speeds we expected. I understand that the SG device uses direct I/O and/or mmap memory from the kernel. What I cannot believe is that there is that much overhead in going through the page buffer/cache system in Linux. We also tried going through a file system (various ones, JFS, XFS, Reiser, Ext3). They all seem to bottleneck at around 400MB/sec, much like /dev/sdb does. We also have a "real" SCSI raid system which also bottlenecks right at 400 MB/sec. Under Windows (XP) both of these systems run at 650 (SCSI) or 800 (SATA) MB/sec. Other variations I've tried: setting the read ahead to larger or smaller number (1, 2, 4, 8, 16, 32, 64 KB)... 8 or 16 seems to be optimal. Using different block sizes in the dd command (again 1, 2, 4, 8, 16, 32, 64). 16, 32, 64 are pretty much identical and fastest. Below is an oprofile (truncated) of (the same) dd running on /dev/sdb. So is the overhead really that high? Hopefully there's a bottleneck in there that no one has come across yet, and it can be optimized. Anyone else trying to pull close to 1GB/sec from disk? :) The kernel has changed a lot since the last time I really worked with it (2.2), so any suggestions are appreciated. Ian Godin Senior Software Developer DTS/Lowry Digital Images --- CPU: P4 / Xeon, speed 3402.13 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10 samples %symbol name 8481858.3510 __copy_to_user_ll 7721727.6026 do_anonymous_page 7015796.9076 _spin_lock_irq 5790245.7009 __copy_user_intel 3616343.5606 _spin_lock 3430183.3773 _spin_lock_irqsave 3074623.0272 kmap_atomic 1933271.9035 page_fault 1810401.7825 schedule 1745021.7181 radix_tree_delete 1589671.5652 end_buffer_async_read 1241241.2221 free_hot_cold_page 1190571.1722 sysenter_past_esp 1173841.1557 shrink_list 1127621.1102 buffered_rmqueue 1054901.0386 smp_call_function 1015681. kmem_cache_alloc 97404 0.9590 kmem_cache_free 95826 0.9435 __rmqueue 95443 0.9397 __copy_from_user_ll 93181 0.9174 free_pages_bulk 92732 0.9130 release_pages 86912 0.8557 shrink_cache 85896 0.8457 block_read_full_page 79629 0.7840 free_block 78304 0.7710 mempool_free 72264 0.7115 create_empty_buffers 71303 0.7020 do_syslog 70769 0.6968 emit_log_char 66413 0.6539 mark_offset_tsc 64333 0.6334 vprintk 63468 0.6249 file_read_actor 63292 0.6232 add_to_page_cache 62281 0.6132 unlock_page 61655 0.6070 _spin_unlock_irqrestore 59486 0.5857 find_get_page 58901 0.5799 drop_buffers 58775 0.5787 do_generic_mapping_read 55070 0.5422 __wake_up_bit 48681 0.4793 __end_that_request_first 47121 0.4639 bad_range 47102 0.4638 submit_bh 45009 0.4431 journal_add_journal_head 41270 0.4063 __alloc_pages 41247 0.4061 page_waitqueue 39520 0.3891 generic_file_buffered_write 38520 0.3793 __pagevec_lru_add 38142 0.3755 do_select 38105 0.3752 do_mpage_readpage 37020 0.3645 vsnprintf 36541 0.3598 __clear_page_buffers 35932 0.3538 journal_put_journal_head 35769 0.3522 radix_tree_lookup 35636 0.3509 bio_put 34904 0.3437 jfs_get_blocks 34865 0.3433 mark_page_accessed 33686 0.3317 bio_alloc 33273 0.3276 __swi
Re: [PATCH] add local bio pool support and modify dm
Dave Olien <[EMAIL PROTECTED]> wrote:
>
> +extern inline void zero_fill_bio(struct bio *bio)
> +{
> +unsigned long flags;
> +struct bio_vec *bv;
> +int i;
> +
> +bio_for_each_segment(bv, bio, i) {
> +char *data = bvec_kmap_irq(bv, &flags);
> +memset(data, 0, bv->bv_len);
> +flush_dcache_page(bv->bv_page);
> +bvec_kunmap_irq(data, &flags);
> +}
> +}
heavens. Why was this made inline? And extern inline?
It's too big for inlining (and is super-slow anyway) and will cause all
sorts of unpleasant header file dependencies for all architectures. bio.h
now needs to see the implementation of everyone's flush_dcache_page(), for
example.
Something like this?
---
25/include/linux/bio.h~add-local-bio-pool-support-and-modify-dm-uninline-zero_fill_bio
2005-02-02 18:17:18.225901376 -0800
+++ 25-akpm/include/linux/bio.h 2005-02-02 18:17:18.230900616 -0800
@@ -286,6 +286,7 @@ extern void bio_set_pages_dirty(struct b
extern void bio_check_pages_dirty(struct bio *bio);
extern struct bio *bio_copy_user(struct request_queue *, unsigned long,
unsigned int, int);
extern int bio_uncopy_user(struct bio *);
+void zero_fill_bio(struct bio *bio);
#ifdef CONFIG_HIGHMEM
/*
@@ -335,18 +336,4 @@ extern inline char *__bio_kmap_irq(struc
__bio_kmap_irq((bio), (bio)->bi_idx, (flags))
#define bio_kunmap_irq(buf,flags) __bio_kunmap_irq(buf, flags)
-extern inline void zero_fill_bio(struct bio *bio)
-{
- unsigned long flags;
- struct bio_vec *bv;
- int i;
-
- bio_for_each_segment(bv, bio, i) {
- char *data = bvec_kmap_irq(bv, &flags);
- memset(data, 0, bv->bv_len);
- flush_dcache_page(bv->bv_page);
- bvec_kunmap_irq(data, &flags);
- }
-}
-
#endif /* __LINUX_BIO_H */
diff -puN
fs/bio.c~add-local-bio-pool-support-and-modify-dm-uninline-zero_fill_bio
fs/bio.c
--- 25/fs/bio.c~add-local-bio-pool-support-and-modify-dm-uninline-zero_fill_bio
2005-02-02 18:17:18.227901072 -0800
+++ 25-akpm/fs/bio.c2005-02-02 18:17:18.231900464 -0800
@@ -182,6 +182,21 @@ struct bio *bio_alloc(int gfp_mask, int
return bio_alloc_bioset(gfp_mask, nr_iovecs, fs_bio_set);
}
+void zero_fill_bio(struct bio *bio)
+{
+ unsigned long flags;
+ struct bio_vec *bv;
+ int i;
+
+ bio_for_each_segment(bv, bio, i) {
+ char *data = bvec_kmap_irq(bv, &flags);
+ memset(data, 0, bv->bv_len);
+ flush_dcache_page(bv->bv_page);
+ bvec_kunmap_irq(data, &flags);
+ }
+}
+EXPORT_SYMBOL(zero_fill_bio);
+
/**
* bio_put - release a reference to a bio
* @bio: bio to release reference to
_
-
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 patch] minor conceptual fix for /proc/kcore header size
Hi, folks. While investigating the 2.4 memory corruption problem fixed by the patch previously posted, it was noticed that the 2.6 version of get_kcore_size() inappropriately uses sizeof(struct memelfnote) in its calculation of the /proc/kcore ELF header size. What is actually stored in the header is an "elf_note" structure plus the 4 ASCII chars "CORE". It just so happens that on 32-bit arches, both calculations result in the same value (16). But on 64-bit arches, the allocated size (24) is larger than necessary (16). This does not result in any possible data corruption, but it might be nice to correct this "conceptual" error. Cheers. -ernie --- linux-2.6.10/fs/proc/kcore.c.orig 2004-12-24 16:34:58.0 -0500 +++ linux-2.6.10/fs/proc/kcore.c2005-02-02 20:44:13.0 -0500 @@ -101,7 +101,7 @@ static size_t get_kcore_size(int *nphdr, } *elf_buflen = sizeof(struct elfhdr) + (*nphdr + 2)*sizeof(struct elf_phdr) + - 3 * sizeof(struct memelfnote) + + 3 * (sizeof(struct elf_note) + 4) + sizeof(struct elf_prstatus) + sizeof(struct elf_prpsinfo) + sizeof(struct task_struct); - 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.4 patch] fix for memory corruption from /proc/kcore access
Hi, Marcelo. A fairly nasty memory corruption potential exists when /proc/kcore is accessed and there are at least 62 vmalloc'd areas. The problem is that get_kcore_size() does not properly account for the elf_prstatus, elf_prpsinfo, and task_struct structure sizes in the fabricated ELF header, and then elf_kcore_store_hdr() and its associated calls to storenote() will possibly overrun the "elf_buf" buffer allocated by read_kcore(). Because the requested buffer size is rounded up to a page multiple, only certain ranges of counts of vmalloc'd areas will actually lead to a memory corruption. When it does happen, usually the end of the /proc/kcore reader's task_struct ends up being copied into a slab page (or sometimes into a data page) causing a kernel crash (or data corruption) at a later point in time. The 1st hunk of the patch below fixes this problem. The latter 3 hunks correct the "p_filesz" value for the note section (which is already initialized to 0 on line 232) as stored in the ELF header, but these hunks are not necessary to fix the corruption possiblity. The fix is already in 2.6. Cheers. -ernie --- linux-2.4.29/fs/proc/kcore.c.orig 2004-08-07 19:26:06.0 -0400 +++ linux-2.4.29/fs/proc/kcore.c2005-02-02 19:52:50.0 -0500 @@ -136,7 +136,10 @@ static unsigned long get_kcore_size(int } *elf_buflen = sizeof(struct elfhdr) + (*num_vma + 2)*sizeof(struct elf_phdr) + - 3 * sizeof(struct memelfnote); + 3 * (sizeof(struct elf_note) + 4) + + sizeof(struct elf_prstatus) + + sizeof(struct elf_prpsinfo) + + sizeof(struct task_struct); *elf_buflen = PAGE_ALIGN(*elf_buflen); return (size - PAGE_OFFSET + *elf_buflen); } @@ -279,7 +282,7 @@ static void elf_kcore_store_hdr(char *bu memset(&prstatus, 0, sizeof(struct elf_prstatus)); - nhdr->p_filesz = notesize(¬es[0]); + nhdr->p_filesz += notesize(¬es[0]); bufp = storenote(¬es[0], bufp); /* set up the process info */ @@ -296,7 +299,7 @@ static void elf_kcore_store_hdr(char *bu strcpy(prpsinfo.pr_fname, "vmlinux"); strncpy(prpsinfo.pr_psargs, saved_command_line, ELF_PRARGSZ); - nhdr->p_filesz = notesize(¬es[1]); + nhdr->p_filesz += notesize(¬es[1]); bufp = storenote(¬es[1], bufp); /* set up the task structure */ @@ -305,7 +308,7 @@ static void elf_kcore_store_hdr(char *bu notes[2].datasz = sizeof(struct task_struct); notes[2].data = current; - nhdr->p_filesz = notesize(¬es[2]); + nhdr->p_filesz += notesize(¬es[2]); bufp = storenote(¬es[2], bufp); } /* end elf_kcore_store_hdr() */ - 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/
i386 HPET code
Hey Venkatesh,
I've been looking into a bug where i386 2.6 kernels do not boot on IBM
e325s if HPET_TIMER is enabled (hpet=disable works around the issue).
When running x86-64 kernels, the issue isn't seen. It appears that after
the hpet is enabled, we stop receiving timer ticks. I've not played on
any other HPET enabled systems, nor have I looked at the HPET spec, so
I'm not sure if this is a hardware issue or not.
The following patch, which uses the x86-64 code for
hpet_timer_stop_set_go() seems to fix the issue.
Your thoughts?
thanks
-john
= arch/i386/kernel/time_hpet.c 1.10 vs edited =
--- 1.10/arch/i386/kernel/time_hpet.c 2004-11-02 06:40:42 -08:00
+++ edited/arch/i386/kernel/time_hpet.c 2005-02-02 17:59:27 -08:00
@@ -64,29 +64,30 @@
{
unsigned int cfg;
- /*
-* Stop the timers and reset the main counter.
-*/
+/*
+ * Stop the timers and reset the main counter.
+ */
+
cfg = hpet_readl(HPET_CFG);
- cfg &= ~HPET_CFG_ENABLE;
+ cfg &= ~(HPET_CFG_ENABLE | HPET_CFG_LEGACY);
hpet_writel(cfg, HPET_CFG);
hpet_writel(0, HPET_COUNTER);
hpet_writel(0, HPET_COUNTER + 4);
- /*
-* Set up timer 0, as periodic with first interrupt to happen at
-* hpet_tick, and period also hpet_tick.
-*/
- cfg = hpet_readl(HPET_T0_CFG);
- cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC |
- HPET_TN_SETVAL | HPET_TN_32BIT;
- hpet_writel(cfg, HPET_T0_CFG);
- hpet_writel(tick, HPET_T0_CMP);
+/*
+ * Set up timer 0, as periodic with first interrupt to happen at hpet_tick,
+ * and period also hpet_tick.
+ */
+
+ hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
+ HPET_TN_32BIT, HPET_T0_CFG);
+ hpet_writel(hpet_tick, HPET_T0_CMP);
+ hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice? */
+
+/*
+ * Go!
+ */
- /*
-* Go!
-*/
- cfg = hpet_readl(HPET_CFG);
cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
hpet_writel(cfg, HPET_CFG);
-
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.4.29] sym53c8xx.c - Add ULL suffix to fix warning
Noticed that in drivers/scsi/sym53c8xx.c:
sym53c8xx.c:13185: warning: integer constant is too large for "long" type
Since we're not dealing with C99 (yet), this 64 bit integer constant
needs to be suffixed with ULL. Patch included.
Mark F. Haigh
[EMAIL PROTECTED]
--- drivers/scsi/sym53c8xx.c.orig 2005-02-02 14:35:52.981929312 -0800
+++ drivers/scsi/sym53c8xx.c2005-02-02 14:38:38.496767232 -0800
@@ -13182,7 +13182,7 @@
** descriptors.
*/
if (chip && (chip->features & FE_DAC)) {
- if (pci_set_dma_mask(pdev, (u64) 0xff))
+ if (pci_set_dma_mask(pdev, (u64) 0xffULL))
chip->features &= ~FE_DAC_IN_USE;
else
chip->features |= FE_DAC_IN_USE;
Re: dm-crypt crypt_status reports key?
On Thu, Feb 03, 2005 at 02:33:01AM +0100, Christophe Saout wrote: > Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall: > > > From looking at the dm_crypt code, it appears that it can be > > interrogated to report the current key. Some quick testing shows: > > > > # dmsetup table /dev/mapper/volume1 > > 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0 > > > > Obviously, root can in principle recover this password from the > > running kernel but it seems silly to make it so easy. > > I already tried that. It took me about five minutes using a shell, dd > and hexdump to get the key out of the running kernel... Indeed. > Yes, the reason is that the device-mapper supports on-the-fly > modifications of the device. cryptsetup has a command to resize the > mapping for example. It can do that without asking for the password > again. Features like this are the reason I'm doing this. Userspace tools > should be able to assume that they can use the result of a table status > command to create a new table with this information. Hmm, interesting. A password per resize is not terribly onerous though. > An alternativ would be to use some form of handle to point to the key > after it has been given to the kernel. But that would require some more > infrastructure. There's been some talk about such infrastructure already. I believe some pieces of it may already be in place. > BTW: The setkey command also seems to return the keys in use for IPSEC > connections. While possibly suboptimal, this won't surprise anyone. But dmsetup has no mention of security in its manpage and doesn't show keys in typical LVM usage. So people might reasonably assume that data from dmsetup tables is not secret. -- Mathematics is the supreme nostalgia of our time. - 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/
[no subject]
Hi Matt, Alan, Could you please tell me (link would do) why it makes default delay_use=5 really necessary (from the patch below)? https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074 7.html It makes USB boot really painfull and slow :( I understand there should be a good reason for it. I've tried to find an answer in archives, without much success though. Thanks, Aleks. - 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 2.6.11-rc2 04/29] ide: cleanup piix
On Wed, 2 Feb 2005 11:46:11 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 04_ide_cleanup_piix.patch > > > > In drivers/ide/pci/piix.[hc], init_setup_piix() is defined and > > used but only one init_setup function is defined and no > > demultiplexing is done using init_setup callback. As other > > drivers call ide_setup_pci_device() directly in such cases, > > this patch removes init_setup_piix() and makes piix_init_one() > > call ide_setup_pci_device() directly. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> applied - 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: your mail
It's basically just like the code says. A lot of devices choke if you access them too quickly after enumeration. The 5 second delay seems to be enough for most devices. But we made it adjustable exactly for people like you. Matt On Wed, Feb 02, 2005 at 04:17:13PM -0800, Aleksey Gorelov wrote: > Hi Matt, Alan, > > Could you please tell me (link would do) why it makes default > delay_use=5 > really necessary (from the patch below)? > https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074 > 7.html > > It makes USB boot really painfull and slow :( > > I understand there should be a good reason for it. I've tried to find > an answer in > archives, without much success though. > > Thanks, > Aleks. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Now payink attention, please. This is mouse. Click-click. Easy to use, da? Now you try... -- Pitr to Miranda User Friendly, 10/11/1998 pgpDzPywIhFwy.pgp Description: PGP signature
Re: [PATCH 2/2] ipv4 routing: multipath with cache support, 2.6.10-rc3
On Mon, 20 Dec 2004 12:19:43 +0100 Einar Lück <[EMAIL PROTECTED]> wrote: > This patch is an approach towards solving some problems with the > current multipath implementation: > * routing cache allows only one route to be cached for a certain > search key > * a mulitpath/load balancing decision is only made in case a > corresponding route is not yet cached > In the scenarios, that are relevant to us (high amount of outgoing > connection requests), this is a serious problem. I agree that per-connection attempt a new multipath decision should be made, but within a flow I disagree. This needs to be flow based. Can you describe more precisely "the scenerios, that are relevant to us"? If you are only interested in more precise multipathing when TCP connections on the local system are made, this we can implement via a flag to the ipv4 routing cache which forces a new multipath decision when TCP sockets have their identity established. We have a precise interface that is invoked at this time, called ip_route_connect(). So that is where we would pass in some flag to indicate that we desire the new multipath behavior. If you want this behavior on a router, you will need to mark the packets using something like firewall marking on the SKB, then this mark would be used at route cache lookup time to determine what kind of multipath decisions to make. There is no way we can enable the new behavior for every routing cache lookup. - 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 2.6.11-rc2 0/29] ide: driver updates
On Wed, 2 Feb 2005 11:40:17 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > Hello, B. Zolnierkiewicz. Hi, > These patches are various fixes/improvements to the ide driver. They > are against the 2.6 bk tree as of today (20050202). Nice series. As you probably already know I merged most of the easy stuff. I will comment on the real stuff soon. Thanks, Bartlomiej - 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 2.6.11-rc2 18/29] ide: comment fixes
On Wed, 2 Feb 2005 12:02:54 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 18_ide_comment_fixes.patch > > > > Comment fixes. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> applied - 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: dm-crypt crypt_status reports key?
Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall: > From looking at the dm_crypt code, it appears that it can be > interrogated to report the current key. Some quick testing shows: > > # dmsetup table /dev/mapper/volume1 > 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0 > > Obviously, root can in principle recover this password from the > running kernel but it seems silly to make it so easy. I already tried that. It took me about five minutes using a shell, dd and hexdump to get the key out of the running kernel... > Moreover, it seems this facility exists to support some form of > automated table storage (LVM?). As we don't want anyone/anything > accidentally storing our passwords on disk in the clear, we probably > shouldn't facilitate this. Perhaps we can stick something here like > "" that the dm_crypt constructor can reject. Yes, the reason is that the device-mapper supports on-the-fly modifications of the device. cryptsetup has a command to resize the mapping for example. It can do that without asking for the password again. Features like this are the reason I'm doing this. Userspace tools should be able to assume that they can use the result of a table status command to create a new table with this information. An alternativ would be to use some form of handle to point to the key after it has been given to the kernel. But that would require some more infrastructure. I could imagine something like this: Some kernel infrastructure for key management. It can hold keys which are referenced by some form of handle. The keys are refcounted and wiped if the reference count drops to zero. If you want to create a dm-crypt mapping (or something else that uses some form of cryptographic key) you create a new handle and assign the key. Then you give the handle to dm-crypt which increments reference count. When cryptsetup exits its reference to the key is dropped but the key still has a reference from the active dm-crypt mapping. Later on another application could then safely do something with that handle. As long as an application or in-kernel user references the key it won't be dropped so it's safe for a userspace application to play around with it. BTW: The setkey command also seems to return the keys in use for IPSEC connections. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Fastboot] [PATCH] Minor Kexec bug fix (2.6.11-rc2-mm2)
"Randy.Dunlap" <[EMAIL PROTECTED]> writes: > Vivek Goyal wrote: > > Hi Andrew, > > This patch has been generated against 2.6.11-rc2-mm2. This fixes a very > > minor bug in kexec. > > Have you run sparse on a kexec-patched kernel tree? > I have, but not lately. It needed some s/0/NULL/ in several places, > but that was before the latest big changes... I have been avoiding adding more but I have not done had a flag day and killed them all either. The one bit int bug was a stupid thinko in the new code. Totally obvious when someone tried it, to use it. I think I am about ready to provide a sysrq panic interface. At least for testing that code path it would be good. And if we actually have kernel core dumps it might be useful beyond that. Eric - 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: Please open sysfs symbols to proprietary modules
Hi, Joseph! On Wed, 2 Feb 2005, Joseph Pingenot wrote: From Pavel Roskin on Wednesday, 02 February, 2005: All I want to do is to have a module that would create subdirectories for some network interfaces under /sys/class/net/*/, which would contain additional parameters for those interfaces. I'm not creating a new subsystem or anything like that. sysctl is not good because the data is interface specific. ioctl on a socket would be OK, although it wouldn't be easily scriptable. The restriction on sysfs symbols would just force me to write a proprietary userspace utility to set those parameters instead of using a shell script. Please pardon my ignorance, but if the existing network device management framework is insufficient, it seems that the optimal way to deal with this is to work with the community to address the insufficiencies, not hacking in a new interface to the device. OK, then the "insufficiency" is inability to set and get additional named variables for network interfaces. I won't open all details, but suppose I want the bridge to handle certain frames in a special way, just like BPDU frames are handled if STP is enabled. There is a hook for that already - see br_handle_frame_hook. The proprietary module would just have to change it. What I want it to tell that module what to do with those special frames. I also want to get information like what was in the last special frame and how many of them have been received. In other words, I want the proprietary module to communicate with userspace. Ideally, the userspace application should be a simple shell script, so I'm reluctant to use ioctl. -- Regards, Pavel Roskin - 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 2.6.11-rc2 14/29] ide: remove NULL checking in ide_error()
On Wed, 2 Feb 2005 11:57:28 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 14_ide_error_remove_NULL_test.patch > > > > In ide_error(), drive cannot be NULL. ide_dump_status() can't > > handle NULL drive. applied, you missed Signed-off-by 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 1/2] ipv4 routing: splitting of ip_route_[in|out]put_slow, 2.6.10-rc3
On Mon, 20 Dec 2004 12:13:24 +0100 Einar Lück <[EMAIL PROTECTED]> wrote: > This patch splits up ip_route_[in|out]put_slow in inlined functions. > Basic idea: > * improve overall comprehensibility > * allow for an easier application of patch for improved multipath > support Patch applied to my 2.6.12 pending tree. Thanks a lot Einar. One minor comment is that there are some minor cases where excessing in_dev get/put can be eliminated. For example, in __mkroute_output() we really only need to do the in_dev_get(dev_out) once, yet we do it twice due to how the return path of this function always puts the reference even in the non-error case. - 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: Please open sysfs symbols to proprietary modules
On Wed, Feb 02, 2005 at 07:07:21PM -0500, Pavel Roskin wrote:
> On Wed, 2 Feb 2005, Greg KH wrote:
> >On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote:
> >>
> >>What is wrong with creating a (GPL'd) abstraction layer that exports
> >>symbols to the proprietary modules?
> >
> >Ick, no!
> >
> >Please consult with a lawyer before trying this. I know a lot of them
> >consider doing this just as forbidden as marking your module
> >MODULE_LICENSE("GPL"); when it really isn't.
>
> There will be a GPL'd layer, and it's likely that sysfs interaction will
> be on the GPL'd side anyway, for purely technical reasons. But it does
> feel like circumvention of the limitations set in the kernel.
It is. And as such, it is not allowed.
> I thought it would be polite to ask the developers to lift those
> limitations, considering that they seem unfair and inconsistent with
> the stated purpose of EXPORT_SYMBOL_GPL.
No, the stated purpose of that marking is to prevent non-GPLd code from
using those symbols. I don't see how you can state that using sysfs
files in your driver does not make it a "derived work" and force you to
make all of your driver GPL.
I suggest that you consult your company's lawyers for what to do here.
Good luck,
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/
CREDITS
Hello, I just thought that in case anyone wants to contact me it would be easier if I was listed in the CREDITS file... N: Neil Whelchel E: [EMAIL PROTECTED] W: http://firstlight.net/~koyama D: Cypress M8 driver, PMD-1280LS driver, USB patches S: P.O. Box 2082 S: Joshua Tree, CA 92252 -Neil Whelchel- First Light Internet Services 760 366-0145 - We don't do Window$, that's what the janitor is for - Bubble Memory, n.: A derogatory term, usually referring to a person's intelligence. See also "vacuum tube". - 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, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
Peter Williams <[EMAIL PROTECTED]> writes: >>> If you have the source code for the programs then they could be >>> modified to drop the root euid after they've changed policy. Or >>> even do the > Paul Davis wrote: >> This is insufficient, since they need to be able to drop RT >> scheduling and then reacquire it again later. > I believe that there are mechanisms that allow this. The setuid man > page states that a process with non root real uid but setuid as root > can use the seteuid call to use the _POSIX_SAVED_IDS mechanism to > drop and regain root privileges as required. Which every system cracker knows. Any attack on such a program is going to re-acquire root privileges and take over the system. Temporarily dropping privileges gains no security whatsoever. It is nothing more than a coding convenience. The program remains *inside* the system security perimeter. -- joq - 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] arp_queue: serializing unlink + kfree_skb
On Mon, 31 Jan 2005 22:33:26 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> We're using atomic integers to signal that we're done with an object.
> The object is usually represented by a piece of memory.
>
> The problem is that in most of the places where we do this (and that's
> not just in the networking systems), there are no memory barriers between
> the last reference to that object and the decrease on the atomic counter.
I agree.
> if (atomic_read(&skb->users) != 1) {
> smp_mb__before_atomic_dec();
> if (!atomic_dec_and_test(&skb->users))
> return;
> }
> __kfree_skb(skb);
This looks good. Olaf can you possibly ask the reproducer if
this patch makes the ARP problem go away?
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/02 15:53:55-08:00 [EMAIL PROTECTED]
# [NET]: Add missing memory barrier to SKB release.
#
# Here, we are using atomic counters to signal that we are done
# with an object. The object is usually represented by a piece
# of memory.
#
# The problem is that in most of the places we do this, there are
# no memory barriers between the last reference to that object
# and the decrease on the atomic counter.
#
# Based upon a race spotted in arp_queue handling by Olaf Kirch.
#
# Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
#
# include/linux/skbuff.h
# 2005/02/02 15:51:57-08:00 [EMAIL PROTECTED] +6 -2
# [NET]: Add missing memory barrier to SKB release.
#
diff -Nru a/include/linux/skbuff.h b/include/linux/skbuff.h
--- a/include/linux/skbuff.h2005-02-02 15:54:13 -08:00
+++ b/include/linux/skbuff.h2005-02-02 15:54:13 -08:00
@@ -353,8 +353,12 @@
*/
static inline void kfree_skb(struct sk_buff *skb)
{
- if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users))
- __kfree_skb(skb);
+ if (atomic_read(&skb->users) != 1) {
+ smp_mb__before_atomic_dec();
+ if (!atomic_dec_and_test(&skb->users))
+ return;
+ }
+ __kfree_skb(skb);
}
/* Use this if you didn't touch the skb state [for fast switching] */
-
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 2.6.11-rc2 13/29] ide: use time_after() macro
On Wed, 2 Feb 2005 11:56:49 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 13_ide_tape_time_after.patch > > > > Explicit jiffy comparision converted to time_after() macro. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> applied - 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 patch] add compiler-gcc4.h
Followup to: <[EMAIL PROTECTED]> By author:Matthias-Christian Ott <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hi! > But maybe gcc 4 will get different later, so I think this patch makes sense. > No, it doesn't. You fork when you have a reason. Eager forking is *BAD*. -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: cpufreq problem wrt suspend/resume on Athlon64
On Wednesday, 2 of February 2005 14:31, Pavel Machek wrote:
> Hi!
>
> > I have noticed that the condition (cur_freq != cpu_policy->cur), which is
> > unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
> > on my box (Athlon64-based Asus). Every time the box resumes, I get a
> > message
> > like that:
> >
> > Warning: CPU frequency out of sync: cpufreq and timing core thinks of
> > 160, is 180 kHz.
> >
> > (the numbers vary: there may be 80 vs 160 or even 80 vs
> > 180).
> >
> > Also, when the box is suspended on AC power and resumed on batteries, it
> > often
> > reboots.
> >
> > Please let me know if there's anything (relatively simple :-)) that I can do
> > about it.
>
> Introduce _suspend() routine to cpufreq, and force cpu to 800MHz
> during suspend().
Do you mean like that:
--- linux-2.6.11-rc2-orig/drivers/cpufreq/cpufreq.c 2005-01-30
23:30:53.0 +0100
+++ linux-2.6.11-rc2/drivers/cpufreq/cpufreq.c 2005-02-03 00:50:05.0
+0100
@@ -939,10 +939,42 @@
return ret;
}
+static int cpufreq_suspend(struct sys_device * sysdev, u32 state)
+{
+ int cpu = sysdev->id;
+ struct cpufreq_policy *cpu_policy;
+
+ dprintk("suspending cpu %u\n", cpu);
+
+ if (!cpu_online(cpu))
+ return 0;
+
+ cpu_policy = cpufreq_cpu_get(cpu);
+ if (!cpu_policy)
+ return -EINVAL;
+
+ /* only handle each CPU group once */
+ if (unlikely(cpu_policy->cpu != cpu)) {
+ cpufreq_cpu_put(cpu_policy);
+ return 0;
+ }
+
+ if (cpufreq_driver->target) {
+ dprintk("cpufreq: trying to set CPU frequency to the minimal
(%u kHz)\n",
+ cpu_policy->min);
+ cpufreq_driver->target(cpu_policy, cpu_policy->min,
+ CPUFREQ_RELATION_L);
+ }
+
+ cpufreq_cpu_put(cpu_policy);
+ return 0;
+}
+
static struct sysdev_driver cpufreq_sysdev_driver = {
.add= cpufreq_add_dev,
.remove = cpufreq_remove_dev,
.resume = cpufreq_resume,
+ .suspend= cpufreq_suspend,
};
> Put it back to right frequency during resume().
Well, I don't know which one is right, because the box might have been
suspended in different conditions (eg AC power vs batteries). I think it's
better to leave it at the minimal frequency for a while. Moreover, I don't
know if it's not necessary to force the minimal frequency again in resume()
(I imagine that some CPUs may change the frequency on the fly if they
are sufficiently loaded, and eg in swsusp we restore the image between
suspend() and resume(), so this may very well happen sometimes, it
seems).
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
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: dm-crypt crypt_status reports key?
On Wed, Feb 02, 2005 at 11:50:02PM +, Alasdair G Kergon wrote: > On Wed, Feb 02, 2005 at 01:19:16PM -0800, Matt Mackall wrote: > > # dmsetup table /dev/mapper/volume1 > > 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0 > > > Obviously, root can in principle recover this password from the > > running kernel but it seems silly to make it so easy. > > There seemed little point obfuscating it - someone will only > write a trivial utility that recovers it. So instead let's do the work for them? We could perhaps put it in the root prompt. Pray tell, what is the value to the user of exposing the whole password, ever? > Consider instead *why* you're worried about the password being > held in RAM and look for better solutions to *your* > perceived threats. My perceived threat, as I've already stated, is that automated suite of utilities like LVM or EVMS or even initscripts will silently store this information in the clear on disk in an effort to make life easier, oblivious to the fact that it might contain security-sensitive information. What drives this perception is that the output of "dmsetup tables" invites it: it appears tailor-made to be fed into a future "dmsetup create". Thus someone clever (but unaware of dm_crypt) _will_ eventually try this if it's not already happening. Further, there is nothing in the dmsetup manpage to suggest that its output should be guarded, etc. See "principle of least surprise." Given the potential risk of naive use of dmsetup tables, what's the upside again? -- Mathematics is the supreme nostalgia of our time. - 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: pci: Arch hook to determine config space size
On Wed, 2005-02-02 at 11:05 +0100, Arnd Bergmann wrote: > How about something along the lines of this patch? Instead of adding a > pointer to the pci data from the device node, it embeds the node inside > a new struct pci_device_node. The patch is not complete and therefore > not expected to work as is, but maybe you want to reuse it. > > The interesting part that is missing is creating and destroying > pci_device_nodes in prom.c, maybe you have an idea how to do that. > > I'm also not sure about eeh. Are the eeh functions known to be called > only for device_nodes of PCI devices? If not, eeh_mode and > eeh_config_addr might have to stay inside of device_node. I'd rather not go that way for now. There are at least PCI and VIO devices concerned by this, and maybe more (depending on how I deal with macio devices for example). We also want, ultimately, to have the DMA routines be function pointers in this auxilliary structure. Ben.
Re: [Fastboot] [PATCH] Minor Kexec bug fix (2.6.11-rc2-mm2)
Vivek Goyal wrote:
Hi Andrew,
This patch has been generated against 2.6.11-rc2-mm2. This fixes a very
minor bug in kexec.
Have you run sparse on a kexec-patched kernel tree?
I have, but not lately. It needed some s/0/NULL/ in several places,
but that was before the latest big changes...
diff -puN include/linux/kexec.h~kexec_minor_bug_fix include/linux/kexec.h
--- linux-2.6.11-rc2-mm2-kdump/include/linux/kexec.h~kexec_minor_bug_fix 2005-02-02 16:28:18.0 +0530
+++ linux-2.6.11-rc2-mm2-kdump-vivek/include/linux/kexec.h 2005-02-02 16:29:01.0 +0530
@@ -79,7 +79,7 @@ struct kimage {
unsigned long control_page;
/* Flags to indicate special processing */
- int type : 1;
+ unsigned int type : 1;
--
~Randy
-
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 2.6.11-rc2 09/29] ide: __ide_do_rw_disk() lba48 dma check fix
On Wed, 2 Feb 2005 11:51:42 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 09_ide_do_rw_disk_lba48_dma_check_fix.patch > > > > In __ide_do_rw_disk(), the shifted block, instead of the > > original rq->sector, should be used when checking range for > > lba48 dma. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> good catch! applied - 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: Copyright / licensing question
Followup to: <[EMAIL PROTECTED]> By author:Charles Cazabon <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > I'm not sure that's the case. Inclusion of significant chunks of source code > (not just a dozen lines or whatever) might bring the book into "derived work" > territory, and your publisher is almost certainly not going to allow > redistribution under the GPL ... > > The short answer is "ask a lawyer". > I think that would fall under the "aggregate work" clause. -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 2.6.11-rc2 11/29] ide: add ide_drive_t.sleeping
On Wed, 2 Feb 2005 11:54:48 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> > 11_ide_drive_sleeping_fix.patch
> >
> > ide_drive_t.sleeping field added. 0 in sleep field used to
> > indicate inactive sleeping but because 0 is a valid jiffy
> > value, though slim, there's a chance that something can go
> > weird. And while at it, explicit jiffy comparisons are
> > converted to use time_{after|before} macros.
Same question as for "add ide_hwgroup_t.polling" patch.
AFAICS drive->sleep is either '0' or 'timeout + jiffies' (always > 0)
-
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 01/04] Adding cipher mode context information to crypto_tfm
Fruhwirth Clemens wrote: > Especially, if James ask me to redo Michal's conflicting patches > (done btw), which are totally off-topic for me. Great, thanks! Has the interface for multiblock modules changed or should my old modules work with it with no more effort? Unfortulately I don't have a PadLock system running at the moment (it is still somewhere down in a wooden box after my moving), but if you send me the patch I could at least try to compile with my parts. Thanks for that! Michal Ludvig - 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 2.6.11-rc2 12/29] ide: add ide_hwgroup_t.polling
On Wed, 2 Feb 2005 11:55:38 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 12_ide_hwgroup_t_polling.patch > > > > ide_hwgroup_t.polling field added. 0 in poll_timeout field > > used to indicate inactive polling but because 0 is a valid > > jiffy value, though slim, there's a chance that something > > weird can happen. Is there really a possibility of something weird? I'm not claiming that I like this way of coding but poll_timeout is assigned either to '0' or to 'jiffies + WAIT_WORSTCASE'. Bartlomiej - 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 2.6.11-rc2 10/29] ide: __ide_do_rw_disk() return value fix
On Wed, 2 Feb 2005 11:52:48 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 10_ide_do_rw_disk_pre_task_out_intr_return_fix.patch > > > > In __ide_do_rw_disk(), ide_started used to be returned blindly > > after issusing PIO write. This can cause hang if > > pre_task_out_intr() returns ide_stopped due to failed > > ide_wait_stat() test. Fixed to pass the return value of > > pre_task_out_intr(). > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> applied - 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 01/04] Adding cipher mode context information to crypto_tfm
On Thu, 03 Feb 2005 01:21:35 +0100 Fruhwirth Clemens <[EMAIL PROTECTED]> wrote: > I'm afraid, I'm not going to change it. I already lost too much time > pushing LRW into the kernel. The work has to be done by somebody. Linus would certainly reject any attempt I would make to push code with that kind of variable naming in it. So instead of blindly going: 1) dave try push to linus 2) linus says fix horrible variable studlyCaps names 3) dave asks patch submitter to fix 4) submitter submits new patch 5) dave retries pushing to linus I'm reducing it to one step, by asking that it be done now, thus saving a lot of wasted time on everyone's part. Submitting your first major patch or set of changes can be incredibly frustrating. It took more than a year before people like Linus would regularly and smoothly integrate my work, most of it would come right back to me for fixups. Don't worry though, if the work is truly variable, someone will pick up the ball and do the necessary coding style fixups et al. to get it integrated. - 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] Linux Kernel Subversion Howto
Followup to: <[EMAIL PROTECTED]> By author:Stelian Pop <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hi, > > I've played lately a bit with Subversion and used it for managing > the kernel sources, using Larry McVoy's bk2cvs bridge and Ben Collins' > bkcvs2svn conversion script. > > Since there is little information on the web on how to properly > set up a SVN repository and use it for tracking the latest kernel > tree, I wrote a small howto (modeled after the bk kernel howto) > in case it can be useful for other people too. > > Feel free to comment on it (but let's not start a new BK flamewar > or SVN bashing session please). If there is enough interest I'll > submit a patch to include this in the kernel Documentation/ > directory. > > I've put it also on my web page along with the necessary scripts: > http://popies.net/svn-kernel/ > > And now a question to Larry and whoever else is involved in the > bkcvs mirror on kernel.org: what is the periodicity of the CVS > repository update ? > Currently it's nightly. Larry has offered to run it more often if someone can provide a dedicated fast machine to run it on. (Larry: is it a matter of memory or of CPU or both? If nothing else we should have the old kernel.org server, dual P3/1133 with 6 GB RAM, coming free soon.) Please let me know if there is something that should be put on kernel.org; we can host repositories there of course. -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: Joe User DOS kills Linux-2.6.10
On Wed, Feb 02, 2005 at 01:23:43PM -0500, linux-os wrote:
>
> When I compile and run the following program:
>
> #include
> int main(int x, char **y)
> {
> pause();
> }
> ... as:
>
> ./xxx `yes`
>
> ... the following occurs after about 30 seconds (your mileage
> may vary):
>
> Additional sense: Peripheral device write fault
> end_request: I/O error, dev sdb, sector 34605780
> SCSI error : <0 0 1 0> return code = 0x802
> Info fld=0x2100101, Deferred sdb: sense key Medium Error
> Additional sense: Peripheral device write fault
> end_request: I/O error, dev sdb, sector 34603748
> SCSI error : <0 0 1 0> return code = 0x802
> Info fld=0x2100103, Deferred sdb: sense key Medium Error
When I run "sleep `yes`" under bash, all of swap space is filled,
and then bash says "realloc error ..." and exits.
No kernel problem, no bad bash problem.
If you do not run vm overcommit mode 2 then probably your bash
will be killed by the OOM killer, and if you are unlucky some
other stuff might be killed as well.
Concerning the SCSI errors, looks like you might have disk problems.
Bad blocks in your swap space. Recheck the disk.
Andries
-
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: Please open sysfs symbols to proprietary modules
Hi, Greg and Patrick!
On Wed, 2 Feb 2005, Greg KH wrote:
On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote:
What is wrong with creating a (GPL'd) abstraction layer that exports
symbols to the proprietary modules?
Ick, no!
Please consult with a lawyer before trying this. I know a lot of them
consider doing this just as forbidden as marking your module
MODULE_LICENSE("GPL"); when it really isn't.
There will be a GPL'd layer, and it's likely that sysfs interaction will
be on the GPL'd side anyway, for purely technical reasons. But it does
feel like circumvention of the limitations set in the kernel. I thought
it would be polite to ask the developers to lift those limitations,
considering that they seem unfair and inconsistent with the stated
purpose of EXPORT_SYMBOL_GPL.
Sorry for using my gnu.org address. I'll use my rajant.com address for
further questions about that project.
--
Regards,
Pavel Roskin
-
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 2.6.11-rc2 06/29] ide: IDE_CONTROL_REG cleanup
On Wed, 2 Feb 2005 11:48:30 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 06_ide_start_request_IDE_CONTROL_REG.patch > > > > Replaced HWIF(drive)->io_ports[IDE_CONTROL_OFFSET] with > > equivalent IDE_CONTROL_REG in ide-io.c. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > > Index: linux-ide-export/drivers/ide/ide-io.c > === > --- linux-ide-export.orig/drivers/ide/ide-io.c 2005-02-02 10:27:15.996184821 > +0900 > +++ linux-ide-export/drivers/ide/ide-io.c 2005-02-02 10:28:03.340503581 > +0900 > @@ -884,7 +884,7 @@ static ide_startstop_t start_request (id > if (rc) > printk(KERN_WARNING "%s: bus not ready on wakeup\n", > drive->name); > SELECT_DRIVE(drive); > - HWIF(drive)->OUTB(8, > HWIF(drive)->io_ports[IDE_CONTROL_OFFSET]); > + HWIF(drive)->OUTB(8, IDE_CONTROL_REG); > rc = ide_wait_not_busy(HWIF(drive), 1); > if (rc) > printk(KERN_WARNING "%s: drive not ready on > wakeup\n", drive->name); IDE_CONTROL_REG macro and co. are obfuscations and should die... - 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 01/04] Adding cipher mode context information to crypto_tfm
On Wed, 2 Feb 2005, James Morris wrote: > Correct, although I think this will get lost in the noise given that it's > sitting in the middle of crypto processing. I'd remove it. Dave just ok'd it, so take his advice over mine :-) - james -- James Morris <[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 01/04] Adding cipher mode context information to crypto_tfm
On Wed, 2005-02-02 at 15:34 -0800, David S. Miller wrote: > Also, I think there will be objections to that studlyCaps naming you > said your other code has. Keep garbage like that in the x11 sources, > if you don't mind :-) I'm afraid, I'm not going to change it. I already lost too much time pushing LRW into the kernel. Coding time: 3 days. Pushing time: 78 days and counting. I'm willing to cancel my work, as I've taken this to matter to an extend, where my time sacrifice can hardly be justified. Especially, if James ask me to redo Michal's conflicting patches (done btw), which are totally off-topic for me. Then, I'm certainly not going to redo all my code, just because someone thinks different about the naming of my variables. -- Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org signature.asc Description: This is a digitally signed message part
Re: Please open sysfs symbols to proprietary modules
>From Pavel Roskin on Wednesday, 02 February, 2005: >All I want to do is to have a module that would create subdirectories for >some network interfaces under /sys/class/net/*/, which would contain >additional parameters for those interfaces. I'm not creating a new >subsystem or anything like that. sysctl is not good because the data is >interface specific. ioctl on a socket would be OK, although it wouldn't >be easily scriptable. The restriction on sysfs symbols would just force >me to write a proprietary userspace utility to set those parameters >instead of using a shell script. Please pardon my ignorance, but if the existing network device management framework is insufficient, it seems that the optimal way to deal with this is to work with the community to address the insufficiencies, not hacking in a new interface to the device. -Joseph -- [EMAIL PROTECTED] Graduate Student in Physics, Freelance Free Software Developer - 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 2.6.11-rc2 03/29] ide: cleanup opti621
On Wed, 2 Feb 2005 11:45:38 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 03_ide_cleanup_opti621.patch > > > > In drivers/ide/pci/opti612.[hc], init_setup_opt621() is > > declared, defined and referenced but never actullay used. > > Thie patch removes the function. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> applied - 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 2.6.11-rc2 02/29] ide: cleanup it8172
On Wed, 2 Feb 2005 11:44:54 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> > 02_ide_cleanup_it8172.patch
> >
> > In drivers/ide/pci/it8172.h, it8172_ratefilter() and
> > init_setup_it8172() are declared and the latter is referenced
> > in it8172_chipsets. Both functions are not defined or used
> > anywhere. This patch removes the prototypes and reference.
> > it8172 should be compilable now.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
applied, also this trivial patch is needed to fix it8172 build:
diff -Nru a/drivers/ide/pci/it8172.c b/drivers/ide/pci/it8172.c
--- a/drivers/ide/pci/it8172.c 2005-02-03 01:00:22 +01:00
+++ b/drivers/ide/pci/it8172.c 2005-02-03 01:00:22 +01:00
@@ -56,7 +56,7 @@
{
ide_hwif_t *hwif= HWIF(drive);
struct pci_dev *dev = hwif->pci_dev;
- int is_slave= (hwif->drives[1] == drive);
+ int is_slave= (&hwif->drives[1] == drive);
unsigned long flags;
u16 drive_enables;
u32 drive_timing;
@@ -94,7 +94,7 @@
}
pci_write_config_word(dev, 0x40, drive_enables);
- spin_unlock_irqrestore(&ide_lock, flags)
+ spin_unlock_irqrestore(&ide_lock, flags);
}
static u8 it8172_dma_2_pio (u8 xfer_rate)
-
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, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
Paul Davis wrote: As Ingo said in an earlier a post, with a little ingenuity this problem can be solved in user space. The programs in question can be setuid root so that they can set RT scheduling policy BUT have their permissions set so that they only executable by owner and group with the group set to a group that only contains those users that have permission to run this program in RT mode. If you wish to allow other users to run the program but not in RT mode then you would need two copies of the program: one set up as above and the other with normal permissions. Just a reminder: setuid root is precisely what we are attempting to avoid. There's nothing wrong with using setuid root if you do it carefully and properly. If you have the sources to the program then you can place all the necessary safeguards in the program itself. Doing this inside the program would allow more elaborate control over who is allowed to set RT policy from within the program. E.g. you could have a file (owned by root and only writable by root) in /etc with the names of the users that have this privilege. If this file does not exist, has the wrong privileges or the user associated with task's ruid is not in the file then the the program immediately and irrevocably drops root privileges otherwise it drops them temporarily and regains them when it needs to either change policy to RT or fork another task that needs the same privileges. If you have the source code for the programs then they could be modified to drop the root euid after they've changed policy. Or even do the This is insufficient, since they need to be able to drop RT scheduling and then reacquire it again later. I believe that there are mechanisms that allow this. The setuid man page states that a process with non root real uid but setuid as root can use the seteuid call to use the _POSIX_SAVED_IDS mechanism to drop and regain root privileges as required. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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: dm-crypt crypt_status reports key?
On Wed, Feb 02, 2005 at 01:19:16PM -0800, Matt Mackall wrote: > # dmsetup table /dev/mapper/volume1 > 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0 > Obviously, root can in principle recover this password from the > running kernel but it seems silly to make it so easy. There seemed little point obfuscating it - someone will only write a trivial utility that recovers it. The current approach has the advantage of making it obvious to you that if you have root access, you have access to the password while the encrypted data volumes are mounted. Consider instead *why* you're worried about the password being held in RAM and look for better solutions to *your* perceived threats. Threat: Someone could run "dmsetup" while I've gone for a coffee break leaving my laptop unattended logged on as root... Threat: My laptop is stolen while it's got a screen saver running (or suspended) and the thief could interrogate RAM and get the password, giving them access to my encrypted data volumes. Possible fixes: Automatically unmount those volumes before starting the screen saver. Automatically unmount them after a certain amount of inactivity. Require the password to be re-entered at regular intervals. New risks: regular entry of password means more chance of its being observed, so consider one-time passwords to gain access to it, or USB dongle periodically inserted etc. etc. Alasdair -- [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 01/04] Adding cipher mode context information to crypto_tfm
On Thu, 3 Feb 2005, Fruhwirth Clemens wrote: > > > +static int ecb_process_gw(void *_priv, int nsg, void **buf) > > > What does _gw mean? > > generic walker.. can be removed, if you like. That's fine, was just wondering. > > > + r = pf(priv, nsl, dispatch_list); > > > + if(unlikely(r < 0)) > > > + goto out; > > > > Not sure if the unlikely() is justified here, given that this is not a > > fast path. I guess it doesn't do any harm. > > I suspected unlikely to be a hint for the compiler to do better jump > prediction and speculations. Remove? Correct, although I think this will get lost in the noise given that it's sitting in the middle of crypto processing. I'd remove it. - James -- James Morris <[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 2.6.11-rc2 01/29] ide: remove adma100
On Wed, 2 Feb 2005 11:43:53 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 01_ide_remove_adma100.patch > > > > Removes drivers/ide/pci/adma100.[hc]. The driver isn't > > compilable (missing functions) and no Kconfig actually enables > > CONFIG_BLK_DEV_ADMA100. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> applied - 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 01/04] Adding cipher mode context information to crypto_tfm
On Thu, 03 Feb 2005 00:28:29 +0100 Fruhwirth Clemens <[EMAIL PROTECTED]> wrote: > I suspected unlikely to be a hint for the compiler to do better jump > prediction and speculations. Remove? I don't think it hurts, keep it in there. When the final patch is made with James's requested fixups, I'll stick this into the 2.6.12 pending tree. Also, I think there will be objections to that studlyCaps naming you said your other code has. Keep garbage like that in the x11 sources, if you don't mind :-) - 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: Copyright / licensing question
Thomas Gleixner <[EMAIL PROTECTED]> wrote: > On Wed, 2005-02-02 at 06:49 -0800, Frank klein wrote: > > I am having some licensing questions. It would be > > really great if you can clarify on them > > > > 1. For explaining the internals of a filesystem in > > detail, I need to take their code from kernel sources > > 'as it is' in the book. Do I need to take any > > permissions from the owner/maintainer regarding this ? > > Will it violate any license if reproduce the driver > > source code in my book ?? > > Legally, not if you mention the licence of the code clearly. I'm not sure that's the case. Inclusion of significant chunks of source code (not just a dozen lines or whatever) might bring the book into "derived work" territory, and your publisher is almost certainly not going to allow redistribution under the GPL ... The short answer is "ask a lawyer". Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.ca/~charlesc/software/ --- - 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 01/04] Adding cipher mode context information to crypto_tfm
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> > James, please test it against ipsec. I'm confident, that everything will
> > work as expected and we can proceed to merge padlock-multiblock against this
> > scatterwalker, so please Andrew, merge after a successful test of James.
>
> This code tests ok with IPSec, and delivers some good performance
> improvements. e.g. FTP transfers over transport mode AES over GigE sped
> up with this patch applied on one side of the connection by 20% for send
> and 15% for receive.
Fine, nice to hear that!
> There are quite a few coding style and minor issues to be fixed (per
> below), and the code should probably then be tested in the -mm tree for a
> while (2.6.11 is too soon for mainline merge).
>
> > +static int ecb_process_gw(void *_priv, int nsg, void **buf)
> What does _gw mean?
generic walker.. can be removed, if you like.
> > +struct cbc_process_priv {
> > + struct crypto_tfm *tfm;
> > + int enc;
> > + cryptfn_t *crfn;
> > + u8 *curIV;
> > + u8 *nextIV;
> > +};
>
> No caps please, I suggest curr_iv and next_iv.
Ack, cipher.c is underscore style. But my LRW private helper lib
gfmulseq.c is going to stay lowerCamelCase. I hope that's ok for
everyone. If not, the one concerned should post a reformat patch.
> > + r = pf(priv, nsl, dispatch_list);
> > + if(unlikely(r < 0))
> > + goto out;
>
> Not sure if the unlikely() is justified here, given that this is not a
> fast path. I guess it doesn't do any harm.
I suspected unlikely to be a hint for the compiler to do better jump
prediction and speculations. Remove?
--
Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
Re: [patch libata-dev-2.6 1/1] libata: sync SMART ioctls with ATA pass thru spec (T10/04-262r7)
Douglas Gilbert wrote: Hopefully these matters will be sorted out at the next t10 meeting in March. So that means I have to hold off releasing SMART support for SATA for yet another couple months? Oh well... 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: [ACPI] [Patch] keep ide disk sleeping when resuming
Hi! > I need this patch (against linux-2.6.11-rc2), to keep ide disk sleeping, > when resuming from ACPI S1. > > In fact, it's just removing a patch from 22 Jun 2004 by Jens Axboe. He has > told me, that "We can probably kill the patch completely". > So, this is what I'm doing now. Are you sure it does not affect S3/S4 in any way? You currently can't easily tell S1 from S3/S4... Please wait with this one. When pm_message_t is introduced (post 2.6.11), we can fix it properly. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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] fix bad locking in drivers/base/driver.c
On Tue, Jan 25, 2005 at 11:10:46AM -0500, Mike Waychison wrote: > Get rid of semaphore abuse by converting device_driver->unload_sem > semaphore to device_driver->unloaded completion. > > This should get rid of any confusion as well as save a few bytes in the > process. > > Signed-off-by: Mike Waychison <[EMAIL PROTECTED]> Thanks, I've applied this to my trees, and it will show up in the next -mm releases. 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: Please open sysfs symbols to proprietary modules
On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote:
>
> What is wrong with creating a (GPL'd) abstraction layer that exports
> symbols to the proprietary modules?
Ick, no!
Please consult with a lawyer before trying this. I know a lot of them
consider doing this just as forbidden as marking your module
MODULE_LICENSE("GPL"); when it really isn't.
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: [2.6 patch] IDE: possible cleanups
On Mon, 31 Jan 2005 20:01:54 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote: > This patch contains the following possible cleanups: > - make some needlessly global code static > - ide-dma.c: remove the unneeded EXPORT_SYMBOL(__ide_dma_test_irq) > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> applied - 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/
