Re: [PATCH] modpost: detect unterminated device id lists
On Sun, 16 Sep 2007 20:45:54 -0700 Kees Cook <[EMAIL PROTECTED]> wrote: > The cleanups you suggested, who should I send those to? Or will you (or > Sam?) make them directly to the kbuild.git tree? (I've never poked at > this part of the kernel source before... I'm unclear on the processes > surrounding it maintainership.) If they hit my inbox they won't get lost.. - 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] modpost: detect unterminated device id lists
On Mon, 17 Sep 2007 05:54:45 +0530 "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> On 9/17/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Wed, 12 Sep 2007 17:49:37 -0700 Kees Cook <[EMAIL PROTECTED]> wrote:
> >
> > > This patch against 2.6.23-rc6 will cause modpost to fail if any device
> > > id lists are incorrectly terminated, after reporting the offender.
> >
> > I'm getting this:
> >
> > rusb2/pvrusb2: struct usb_device_id is 20 bytes. The last of 3 is:
> > 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> > 0x00 0x00 0x00 0x00 0x00
> > FATAL: drivers/media/video/pvrusb2/pvrusb2: struct usb_device_id is not
> > terminated
> > with a NULL entry!
> >
> > ("rusb2/pvrusb2" ??)
>
> Hmm? Are you sure you didn't see any "drivers/media/video/pv" before the
> "rusb2/pvrusb2" bit?
Fairly. I looked twice.
> Looking at Kees' patch (and the existing code), I've no
> clue how/why this should happen ... will try to reproduce here ...
>
>
> > but:
> >
> > struct usb_device_id pvr2_device_table[] = {
> > [PVR2_HDW_TYPE_29XXX] = { USB_DEVICE(0x2040, 0x2900) },
> > [PVR2_HDW_TYPE_24XXX] = { USB_DEVICE(0x2040, 0x2400) },
> > { USB_DEVICE(0, 0) },
> > };
> >
> > looks OK?
> >
> > Using plain old "{ }" shut the warning up.
>
> USB_DEVICE(0, 0) is not empty termination, actually, and this looks like
> a genuine bug caught by the patch. As that dump shows, USB_DEVICE(0, 0)
> assigns "0x03 0x00" (in little endian) to usb_device_id.match_flags. And
> I don't think the USB code treats such an entry as an empty entry (?)
>
> Interestingly, the "USB_DEVICE(0, 0)" thing is absent from latest -git
> tree and also in my copy of 23-rc4-mm1 -- so this looks like something
> you must've merged recently.
git-dvb very carefully does
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c~git-dvb
+++ a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -44,7 +44,7 @@
struct usb_device_id pvr2_device_table[] = {
[PVR2_HDW_TYPE_29XXX] = { USB_DEVICE(0x2040, 0x2900) },
[PVR2_HDW_TYPE_24XXX] = { USB_DEVICE(0x2040, 0x2400) },
- { }
+ { USB_DEVICE(0, 0) },
};
MODULE_DEVICE_TABLE(usb, pvr2_device_table);
-
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/
3 YTL ye Program-egitim cd si gordunuzmu?
arkadaslar gercekten para kazanmak istiyormusunuz oyleyse asagidaki linki tikla arkadaslarini uye yap cep telefonuna gelen reklam sms lerinden para kazan.. mailine gelen reklamlardan para kazan... isin acigi sen istesende istemesende bu reklamlar sana geliyor.. en iyisimi para kazan hemde gercekten tatmin edici bir miktar bu asagidaki linke benim referansim ile uye olursan avantlarimdan faydalanirsin fazladan 45 ytl lik uyelik pirimin benden... bunuda istedigin gibi harcamak sana kalmis... ister alisveris yap... ister biriktir.. tek yapman gereken uye olmak icin asagidaki line tıklamak bilgileri girmek https://www.superteklif.com/super-uye-formu.aspx?rid=OmFKi07lchY_eql - 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: Wasting our Freedom
Daniel Hazelton wrote: > On Sunday 16 September 2007 23:00:09 Can E. Acar wrote: [snip] >> Theo summarized the latest situation here, some days ago: >> >> http://marc.info/?l=openbsd-misc&m=118963284332223&w=2 >> >> and here is a very brief summary: >> >> http://marc.info/?l=openbsd-misc&m=118965266709012&w=2 >> >> If you really want to know the latest situation, please read these >> links, and think about it. > > No need. Here are the facts: It is now obvious that you have no interest in facts, You blindly repeat what you made yourself to believe. I will waste no more time with you. Can -- In theory, there is no difference between theory and practice. But, in practice, there is. - 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 09/10] ppc64: Convert cpu_sibling_map to a per_cpu data array (v3)
On Mon, 17 Sep 2007 16:28:31 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > the topology (on my POWERPC5+ box) is not correct: > > cpu0/topology/thread_siblings:000f > cpu1/topology/thread_siblings:000f > cpu2/topology/thread_siblings:000f > cpu3/topology/thread_siblings:000f > > it used to be: > > cpu0/topology/thread_siblings:0003 > cpu1/topology/thread_siblings:0003 > cpu2/topology/thread_siblings:000c > cpu3/topology/thread_siblings:000c This would be because we are setting up the cpu_sibling map before we call setup_per_cpu_areas(). -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpatNBZ0XOMA.pgp Description: PGP signature
Re: [PATCH] Wake up mandatory locks waiter on chmod
J. Bruce Fields wrote: > On Thu, Sep 13, 2007 at 06:30:43PM +0400, Pavel Emelyanov wrote: >> When the process is blocked on mandatory lock and someone changes >> the inode's permissions, so that the lock is no longer mandatory, >> nobody wakes up the blocked process, but probably should. > > I suppose so. Does anyone actually use mandatory locking? :) Good question. > Would it be worth adding a > > if (MANDATORY_LOCK(inode)) > return; > > to the beginning of locks_wakeup_mandatory() to avoid walking the list > of locks in that case? Perhaps setattr is rare enough that this just > isn't worth caring about. > > Is there a small chance that a lock may be applied after this check: > >> +mandatory = (inode->i_flock && MANDATORY_LOCK(inode)); >> + > > but early enough that someone can still block on the lock while the file > is still marked for mandatory locking? (And is the inode->i_flock check > there really necessary?) There is, but as you have noticed: > Well, there are probably worse races in the mandatory locking code. ...there are. The inode->i_lock is protected with lock_kernel() only and is not in sync with any other checks for inodes. This is sad :( but a good locking for locks is to be done... > (For example, my impression is that a mandatory lock can be applied just > after the locks_mandatory_area() checks but before the io actually > completes.) > > --b. Thanks, Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/10] ppc64: Convert cpu_sibling_map to a per_cpu data array (v3)
On Tue, 11 Sep 2007 18:56:53 -0700 [EMAIL PROTECTED] wrote: > > Convert cpu_sibling_map to a per_cpu cpumask_t array for the ppc64 > architecture. This fixes build errors in block/blktrace.c and > kernel/sched.c when CONFIG_SCHED_SMT is defined. > > Note: these changes have not been built nor tested. After applying all 10 patches, the ppc64_defconfig builds but: vmlinux is larger: textdata bss dec hex filename 7705776 1756984 504624 9967384 981718 ppc64/vmlinux 7706228 1757120 504624 9967972 981964 trav.bld/vmlinux the topology (on my POWERPC5+ box) is not correct: cpu0/topology/thread_siblings:000f cpu1/topology/thread_siblings:000f cpu2/topology/thread_siblings:000f cpu3/topology/thread_siblings:000f it used to be: cpu0/topology/thread_siblings:0003 cpu1/topology/thread_siblings:0003 cpu2/topology/thread_siblings:000c cpu3/topology/thread_siblings:000c Similarly on my iSeries box, the topology is displayed as above while it used to be: cpu0/topology/thread_siblings:0001 cpu1/topology/thread_siblings:0002 cpu2/topology/thread_siblings:0004 cpu3/topology/thread_siblings:0008 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpmY9QJV3fe4.pgp Description: PGP signature
Re: [PATCH 2/2] Fix user namespace exiting OOPs
Andrew Morton wrote: > On Fri, 14 Sep 2007 13:23:55 -0500 "Serge E. Hallyn" <[EMAIL PROTECTED]> > wrote: > >>> run on kernel with CONFIG_USER_NS turned on will oops the >>> kernel immediately. >>> >>> This was spotted during OpenVZ kernel testing. >>> >>> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> >>> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> >> Good spot. Interesting solution :) >> > > Do we want to fix this in 2.6.23? This is not a security issue at all. This BUG can be triggered only by CAP_SYS_ADMIN capable task on the kernel with CONFIG_USER_NS=y, which is an EXPERIMENTAL depending option. > If so then at present I'll need to merge > > kernel-userc-use-list_for_each_entry-instead-of-list_for_each.patch > convert-uid-hash-to-hlist.patch > fix-user-namespace-exiting-oops.patch > > which is rather a lot of merging at this stage - surely more than > is really needed? > Thanks, Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
On Sunday 16 September 2007 23:00:09 Can E. Acar wrote: > Daniel Hazelton wrote: > > On Sunday 16 September 2007 14:48:47 Can E. Acar wrote: > > [snip] > > >> First, these developers got questionable advice from senior Linux kernel > >> developers, and SLFC (which is closely related to FSF) in the process. > > > > IIRC, the advice was "Yes, it is legal to choose to follow only one of > > multiple offered licenses on a project" - nothing else. They looked at > > the patches and said "Wait, you've changed the license on files that > > aren't under a dual license." > > > > Hence, no problems here - no questionable advice only. > > The replies suggest that some (most?) people are not aware of the > recent developments, and that it is a dual licensing issue. Look at what I replied to and then thank me for replying to the text in question. Or is the fact that I was responding to - > >> First, these developers got questionable advice from senior Linux kernel > >> developers, and SLFC (which is closely related to FSF) in the process. - somehow beyond your comprehension? > This has very little to do with dual licensing right now, > there has been other developments, more "advice" from SLFC. And I have seen absolutely none of said "advice". > The code in question is Reyk's open source HAL work. > I want to emphasize. This work was NOT ever dual licensed. And that was only in question *PRIOR* to the review and rejection of the patches in question. Comprende ? > Furthermore, since it is compatible with the binary HAL from > Atheros, the interface is fixed and the same both in Linux and > *BSD. So, even the latst code divergence arguments do not > apply here. The improvements to this piece of code improve > the Open Source Atheros support, and is important for both > Linux and BSD. Doubtful. If I wrote a HAL implementation from scratch using Reyk's code as a reference only would that make my bottom-up rewrite a derivative? If you think it would, then you need to stop talking and start listening. Just because the code needs to provide a specific interface does not mean that any specific persons implementation is a derivative of another. This simple fact is key - because if that fact wasn't true then the original, purely binary HAL that was/is in FreeBSD would be illegal, as would Reyk's code. > Theo summarized the latest situation here, some days ago: > > http://marc.info/?l=openbsd-misc&m=118963284332223&w=2 > > and here is a very brief summary: > > http://marc.info/?l=openbsd-misc&m=118965266709012&w=2 > > If you really want to know the latest situation, please read these > links, and think about it. No need. Here are the facts: 1) People have come to the Linux Kernel ML and complained about a set of patches that were never accepted. 2) Theo has accused a Kernel developer of telling people to break the law. 3) People show up complaining again, apparently about the same patches. 4) One of them points out that the MadWifi developers have taken the broken patches 5) Several people on LKML say "So go be a troll there, leave us alone" 6) The original people, and more, start with claims that the Linux Kernel developers should "police" the "GNU/FSF/GPL Community" And now you come here saying that people don't understand the situation. Go look at the first two links in Theo's mails, which you linked to. Are they to kernel.org git repo's? Is either of them for the "linux-wireless-2.6" git repo? The answer to both is "No" - they are to MadWifi - a system which is developed separate from the Linux Kernel and not discussed here. The other two links are to a git repo that hasn't been included in the Linux Kernel, but probably will be, since it doesn't violate anyones copyright. Is Theo happy? No. Because the two people that ported to code to work in Linux have added themselves as holding copyrights to portions of the code. "Those files are still invalidly being distributed -- Nick and Jiri did not proveably do enough original work to earn copyright on a derivative work, since their work is just an adaptation." Now think about it - there are files that they have modified - in some cases this was apparently quite a bit of work. Yet they can't place their own copyrights on the code because Theo thinks it all is "Just an Adaptation" ? Think about this: Linux runs on numerous hardware platforms. For each platform there is a "port" - and "adaptation" of the code to make the kernel capable of running as fast and as stably on the new platform as the original supported one. Each one of those "ports" is an "adaptation" of existing code. By Theo's reckoning - judging from the statement I've quoted - none of them are worthy of a copyright, because they are "Just an adaptation". For instance, compare src/sys/dev/ic/ar5xxx.h to ath5k.h (they appear to be the same file) - there was a *LOT* of work done in this file. I truthfully can't tell how much of the original remains and how much has been re
Re: crashme fault
On Sun, 16 Sep 2007, Randy Dunlap wrote: > > I'll test this overnight on 2.6.23-rc6-git2 since that was failing. > > I haven't been able to reproduce the fault on 2.6.21 after several > hours of testing. > > I'll also test a microcode update to see if it helps. Before you do the microcode update, try to see if you can bisect the place between 2.6.21->22 that seems to start it. Even if you don't get all the way, if you are confident enough about the "no error" case to be able to bisect it down by doing a few reboots, it will at least cut down the set of possible commits by roughly a factor of 2^ events, so even "just" a series of 4-5 bisect things might give us more of a clue. Of course, if it's somewhat random and timing-dependent, bisection can be hard (the "2^n" thing is very efficient, but it also means that a *single* wrong answer will totally invalidate the result, so if something isn't entirely reproducible, bisection often fails!) Linus - 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: crashme fault
On Sun, 16 Sep 2007 11:12:23 -0700 (PDT) Linus Torvalds wrote: > > > On Sun, 16 Sep 2007, Linus Torvalds wrote: > > > > I'm really starting to suspect some early EM64T bug, and I also suspect > > that it's harmless but that we should just do the trivial patch to say "if > > the register state is in user mode, we don't care if the CPU says it was a > > kernel access". > > Namely something like this.. > > The basic idea is that it's pointless to test for "error_code & PF_USER" > to decide whether we should oops or kill the process: the *real* issue is > whether we *can* kill the process or not. And that depends not on whether > the CPU claimed it was a user access or not, but on whether the register > state we'd return to is user-mode or not! > > So anything that decides whether it should send a signal or do to the > "no_context" Ooops path should use "user_mode_vm(regs)" (yeah, I realize > that the "_vm" part is unnecessary on x86-64, but it doesn't hurt either, > and all of the issues are the same on 32/64-bit) which tests the right > thing. > > Now, normally the USER bit in the error code should be the exact same > thing, except for > > - Some CPU bug (microcode issue, whatever) where some complex fault >situation sets the wrong error code. > > - user space accesses that caused a system page fault (ie a page fault >while handling another trap - possibly due to lazy page table setup >and having the LDT or some other CPU data structure in vmalloc space) > > Now, the vmalloc space accesses should be handled separately anyway, so I > really wonder if it's some subtle CPU bug (I can't reproduce any problems > on my Core 2 Duo), but the point is that I think this patch really is > conceptually a real fix regardless, even if it _shouldn't_ matter. > > Comments? > > Randy, this replaces the hacky patch I sent, but also shuts up about the > odd thing you're hitting, so for testing your case further this may not be > the right thing. However, it would be nice to hear whether this just makes > "crashme" work properly for you without any side effects.. I'll test this overnight on 2.6.23-rc6-git2 since that was failing. I haven't been able to reproduce the fault on 2.6.21 after several hours of testing. I'll also test a microcode update to see if it helps. --- ~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/
[GIT PATCH] ACPI patches for 2.6.23-rc6
Hi Linus, Before 2.6.23, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release A build fix, a kconfig fix, a typo and a revert for the thinkpad folks. This will update the files shown below. thanks! -Len ps. individual patches are available on [EMAIL PROTECTED] and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.23/acpi-release-20070126-2.6.23-rc6.diff.gz Documentation/thinkpad-acpi.txt | 96 ++ drivers/acpi/event.c|2 drivers/acpi/sleep/proc.c | 10 - drivers/misc/Kconfig| 20 --- drivers/misc/msi-laptop.c |2 drivers/misc/thinkpad_acpi.c| 144 drivers/misc/thinkpad_acpi.h|1 7 files changed, 172 insertions(+), 103 deletions(-) through these commits: Christian Borntraeger (1): ACPI: (more) delete CONFIG_ACPI_PROCFS_SLEEP (again) Henrique de Moraes Holschuh (3): ACPI: fix CONFIG_NET=n acpi_bus_generate_netlink_event build failure ACPI: thinkpad-acpi: revert new 2.6.23 CONFIG_THINKPAD_ACPI_INPUT_ENABLED option ACPI: thinkpad-acpi: bump up version to 0.16 Jonathan Woithe (1): msi-laptop: replace ',' with ';' with this log: commit ecfe7f093768f7af0959f5be8ec039dcc29724af Merge: 95e3f66... 3b0c648... Author: Len Brown <[EMAIL PROTECTED]> Date: Mon Sep 17 00:58:40 2007 -0400 Pull thinkpad into release branch commit 3b0c6485a733f5f0f5c362fb094df1466b18ab93 Author: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Date: Tue Sep 4 11:13:16 2007 -0300 ACPI: thinkpad-acpi: bump up version to 0.16 Name it thinkpad-acpi version 0.16 to avoid any confusion with some 0.15 thinkpad-acpi development snapshots and backports that had input layer support, but no hotkey_report_mode support. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit ff80f1370f2eff7dd7a828cf2416bf7be697247e Author: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Date: Tue Sep 4 11:13:15 2007 -0300 ACPI: thinkpad-acpi: revert new 2.6.23 CONFIG_THINKPAD_ACPI_INPUT_ENABLED option Revert new 2.6.23 CONFIG_THINKPAD_ACPI_INPUT_ENABLED Kconfig option because it would create a legacy we don't want to support. CONFIG_THINKPAD_ACPI_INPUT_ENABLED was added to try to fix an issue that is now moot with the addition of the netlink ACPI event report interface to the ACPI core. Now that ACPI core can send events over netlink, we can use a different strategy to keep backwards compatibility with older userspace, without the need for the CONFIG_THINKPAD_ACPI_INPUT_ENABLED games. And it arrived before CONFIG_THINKPAD_ACPI_INPUT_ENABLED made it to a stable mainline kernel, even, which is Good. This patch is in sync with some changes to thinkpad-acpi backports, that will keep things sane for userspace across different combinations of kernel versions, thinkpad-acpi backports (or the lack thereof), and userspace capabilities: Unless a module parameter is used, thinkpad-acpi will now behave in such a way that it will work well (by default) with userspace that still uses only the old ACPI procfs event interface and doesn't care for thinkpad-acpi input devices. It will also always work well with userspace that has been updated to use both the thinkpad-acpi input devices, and ACPI core netlink event interface, regardless of any module parameter. The module parameter was added to allow thinkpad-acpi to work with userspace that has been partially updated to use thinkpad-acpi input devices, but not the new ACPI core netlink event interface. To use this mode of hot key reporting, one has to specify the hotkey_report_mode=2 module parameter. The thinkpad-acpi driver exports the value of hotkey_report_mode through sysfs, as well. thinkpad-acpi backports to older kernels, that do not support the new ACPI core netlink interface, have code to allow userspace to switch hotkey_report_mode at runtime through sysfs. This capability will not be provided in mainline thinkpad-acpi as it is not needed there. Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Cc: Michael S. Tsirkin <[EMAIL PROTECTED]> Cc: Hugh Dickins <[EMAIL PROTECTED]> Cc: Richard Hughes <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> commit 95e3f66fa60a8e573b0b7a58305c5c9fcbca1b70 Merge: 5e41d0d... 66baf32... Author: Len Brown <[EMAIL PROTECTED]> Date: Mon Sep 17 00:28:58 2007 -0400 Pull misc into release branch commit 66baf327ae5d4c17e75d1f501145e79eaeeaf649 Author: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Date: Mon Sep 3 00:03:35 2007 -0300 ACPI: fix CONFIG_NET=n acpi_bus_generate_netlink_event build fai
Re: [00/41] Large Blocksize Support V7 (adds memmap support)
On Fri, Sep 14, 2007 at 06:48:55AM +1000, Nick Piggin wrote: > On Thursday 13 September 2007 12:01, Nick Piggin wrote: > > On Thursday 13 September 2007 23:03, David Chinner wrote: > > > Then just do operations on directories with lots of files in them > > > (tens of thousands). Every directory operation will require at > > > least one vmap in this situation - e.g. a traversal will result in > > > lots and lots of blocks being read that will require vmap() for every > > > directory block read from disk and an unmap almost immediately > > > afterwards when the reference is dropped > > > > Ah, wow, thanks: I can reproduce it. > > OK, the vunmap batching code wipes your TLB flushing and IPIs off > the table. Diffstat below, but the TLB portions are here (besides that > _everything_ is probably lower due to less TLB misses caused by the > TLB flushing): > > -170 -99.4% sn2_send_IPI > -343 -100.0% sn_send_IPI_phys > -17911 -99.9% smp_call_function > > Total performance went up by 30% on a 64-way system (248 seconds to > 172 seconds to run parallel finds over different huge directories). Good start, Nick ;) > > 23012 54790.5% _read_lock > 9427 329.0% __get_vm_area_node > 5792 0.0% __find_vm_area > 1590 53000.0% __vunmap _read_lock? I though vmap() and vunmap() only took the vmlist_lock in write mode. > Next I have some patches to scale the vmap locks and data > structures better, but they're not quite ready yet. This looks like it > should result in a further speedup of several times when combined > with the TLB flushing reductions here... Sounds promising - when you have patches that work, send them my way and I'll run some tests on them. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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] modpost: detect unterminated device id lists
Hi Satyam,
On Mon, Sep 17, 2007 at 06:52:52AM +0530, Satyam Sharma wrote:
> On 9/13/07, Kees Cook <[EMAIL PROTECTED]> wrote:
> >
> > This patch against 2.6.23-rc6 will cause modpost to fail if any device
> > id lists are incorrectly terminated, after reporting the offender.
> >
> > Signed-off-by: Kees Cook <[EMAIL PROTECTED]>
>
> Nice! :-)
>
> BTW a very similar idea (but for a different problem) was discussed in:
> http://lkml.org/lkml/2007/8/23/48
>
> I tried doing something about that, but gave up in between. For the
> device_id tables, a lot of infrastructure/code already exists in modpost,
> but no such luck for kobjects :-( Still, if you can do something about
> that, as he mentioned, I bet Greg would gladly accept such a patch :-)
Thanks! Hmm, perhaps I'll take that on when I learn kobjects better. :)
> > +static void device_id_check(const char *modname, const char *device_id,
> > + unsigned long size, unsigned long id_size,
> > + void *symval)
>
> If you pass the Elf_Sym *sym all the way from handle_moddevtable() (which
> means you can get rid of the sym->st_size argument in the call chain), then
> it would be possible to print out the *symbol name* too here ...
That's true. I actually threw away an earlier version of this patch
that made some extensive changes to the elf parser (due to the NOBITS
thing I explain below), but instead opted for the smaller version that
stayed out of there.
> for (p = symval+size-id_size; p < symval+size; p++) {
> if (*p) {
>
> is probably clearer ?
Ah, yeah, that's much nicer. I think I must have still have my ELF
parser hat on when I wrote that. ;)
> As I just said, printing out just the modname and device_id "type" sounds
> insufficient here. Note that they were sufficient before your patch, because
> previously, this function only checked if the device_id *type* itself was
> incorrectly defined. But here we're talking about a specific errant *symbol*.
That's true, yeah.
> > + fprintf(stderr,"\n");
> > + fatal("%s: struct %s_device_id is not terminated "
> > + "with a NULL entry!\n", modname, device_id);
>
> Subtle nit, but it's not really a "NULL" entry. It's an "empty object" entry,
> not a "NULL" pointer ... how about replacing "a NULL" with "an empty" ?
Yeah, that bugged me when I put that in too. :) Yes, "an empty" is
better.
> > @@ -527,14 +542,22 @@ void handle_moddevtable(struct module *m
> > Elf_Sym *sym, const char *symname)
> > {
> > void *symval;
> > + char *zeros = NULL;
> >
> > /* We're looking for a section relative symbol */
> > if (!sym->st_shndx || sym->st_shndx >= info->hdr->e_shnum)
> > return;
> >
> > - symval = (void *)info->hdr
> > - + info->sechdrs[sym->st_shndx].sh_offset
> > - + sym->st_value;
> > + /* Handle all-NULL symbols allocated into .bss */
> > + if (info->sechdrs[sym->st_shndx].sh_type & SHT_NOBITS) {
> > + zeros = calloc(1, sym->st_size);
> > + symval = zeros;
> > + }
>
> Hmm, I don't quite grok this case. Care to explain?
In the ELF format, the .bss segment is initialized by the loader to all
zeros, but it contains no in-file representation (since it's all zeros
and would be a waste of space). Such segments are flags as "SHT_NOBITS"
meaning that the loader must allocate cleared memory instead of loading
the segment from the file.
In the case of modules that have a totally empty *_device_id list (?!),
the compiler optimizes this into the .bss segment, since there is no need
to store an all-zero-contents object in a segment that would be loaded
from the file itself.
As a result, attempting to dereference such a symbol without noticing
the SHT_NOBITS flag lands you somewhere in uninitialized memory. So,
the above code basically side-steps the incorrect symbol location
calculation and just aims it at a cleared part of memory.
As I mentioned, there was a larger patch that attempted to sort this
out in the elf parser, but I didn't like it; it was big, not 100%
correct, and the above approach seemed like a much less invasive change.
The cleanups you suggested, who should I send those to? Or will you (or
Sam?) make them directly to the kbuild.git tree? (I've never poked at
this part of the kernel source before... I'm unclear on the processes
surrounding it maintainership.)
Thanks!
-Kees
--
Kees Cook
-
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: Wasting our Freedom
> You did say otherwise. > > Your claim was that "You can obtain, *from the GPL*, the right to remove > a BSD license notice." > > This claim is bullshit. No, it's not. > You can get this right from the copyright holder, e.g. when he > dual-licenced his code, but you can not get this right from the GPL. By that argument, the GPL never grants anyone any rights, they always come from the copyright holder. For dual-licensed code, it's the GPL that gives you the right to remove the BSD license notice. The copyright holder says you may distribute and modify the code under either license. That doesn't let you remove the text of the other license by itself. For example, if both the BSD and the GPL licenses said you could not modify *any* license text, then you still couldn't remove the other license since neither one would give you that right. However, both the GPL and the BSD license grant the right to modify. Neither requires you to keep any license notices intact except those that refer to that same license. If you read the GPL carefully, you will see that it requires you to keep intact all notices that refer to *this* license, that is, the GPL. Similary, the BSD license requires you to keep the BSD license notice intact, but not any other licenses. That is, the original author, by permitting you to obtain the right to modify his work from the GPL, has indirectly granted you the right to remove the BSD license. The GPL grants this right, and the author has permitted you to opt for that license. DS - 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: Wasting our Freedom
Can E. Acar wrote: Furthermore, since it is compatible with the binary HAL from Atheros, the interface is fixed and the same both in Linux and *BSD. Hardly. It is software; the interface most definitely can and will change. 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/
[PATCH] Blackfin EMAC driver: add a select for the PHYLIB of this driver
Since we are adding requirement for the PHYLIB for this driver, there should be a select for that Cc: Robin Getz <[EMAIL PROTECTED]> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- drivers/net/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 5b9e17b..5eef224 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -843,6 +843,8 @@ config BFIN_MAC tristate "Blackfin 536/537 on-chip mac support" depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H) select CRC32 + select MII + select PHYLIB select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE help This is the driver for blackfin on-chip mac device. Say Y if you want it -- 1.5.2 - 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/3] Blackfin EMAC driver: Add phyabstraction layer supporting in bfin_emac driver
On Sun, 2007-09-16 at 22:51 -0400, Robin Getz wrote: > On Sat 15 Sep 2007 22:57, Bryan Wu pondered: > > > > - add MDIO functions and register mdio bus > > - add phy abstraction layer (PAL) functions and use PAL API > > - test on STAMP537 board > > Today, the Kconfig for the Blackfin just includes: > > > config BFIN_MAC > > tristate "Blackfin 536/537 on-chip mac support" > > depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H) > > select CRC32 > > select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE > > help > > This is the driver for blackfin on-chip mac device. Say Y if you > > want it compiled into the kernel. This driver is also available as a module > > ( = code which can be inserted in and removed from the running kernel > > whenever you want). The module will be called bfin_mac. > > Since you are adding requirement for the PHYLIB with this patch, should there > be a select for that? > > -Robin OK, I will send a patch for this update, since some people failed to compile the kernel without select the PHYLIB. Thanks -Bryan Wu - 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: Wasting our Freedom
Daniel Hazelton wrote: > On Sunday 16 September 2007 14:48:47 Can E. Acar wrote: [snip] >> >> First, these developers got questionable advice from senior Linux kernel >> developers, and SLFC (which is closely related to FSF) in the process. > > IIRC, the advice was "Yes, it is legal to choose to follow only one of > multiple offered licenses on a project" - nothing else. They looked at the > patches and said "Wait, you've changed the license on files that aren't under > a dual license." > > Hence, no problems here - no questionable advice only. The replies suggest that some (most?) people are not aware of the recent developments, and that it is a dual licensing issue. This has very little to do with dual licensing right now, there has been other developments, more "advice" from SLFC. The code in question is Reyk's open source HAL work. I want to emphasize. This work was NOT ever dual licensed. Furthermore, since it is compatible with the binary HAL from Atheros, the interface is fixed and the same both in Linux and *BSD. So, even the latst code divergence arguments do not apply here. The improvements to this piece of code improve the Open Source Atheros support, and is important for both Linux and BSD. Theo summarized the latest situation here, some days ago: http://marc.info/?l=openbsd-misc&m=118963284332223&w=2 and here is a very brief summary: http://marc.info/?l=openbsd-misc&m=118965266709012&w=2 If you really want to know the latest situation, please read these links, and think about it. Do you believe re-arranging code, renaming functions, splitting code to multiple files, adding some adaptation code is original enough to be a derivative work and deserve its own copyright? Can -- In theory, there is no difference between theory and practice. But, in practice, there is. - 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/3] Blackfin EMAC driver: Add phyabstraction layer supporting in bfin_emac driver
On Sat 15 Sep 2007 22:57, Bryan Wu pondered: > > - add MDIO functions and register mdio bus > - add phy abstraction layer (PAL) functions and use PAL API > - test on STAMP537 board Today, the Kconfig for the Blackfin just includes: > config BFIN_MAC > tristate "Blackfin 536/537 on-chip mac support" > depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H) > select CRC32 > select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE > help > This is the driver for blackfin on-chip mac device. Say Y if you > want it compiled into the kernel. This driver is also available as a module > ( = code which can be inserted in and removed from the running kernel > whenever you want). The module will be called bfin_mac. Since you are adding requirement for the PHYLIB with this patch, should there be a select for that? -Robin - 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: iunique() fails to return ino_t (after commit 866b04fccbf125cd)
On 9/17/07, Jeff Layton <[EMAIL PROTECTED]> wrote: > On Mon, 17 Sep 2007 00:58:54 +0530 > "Satyam Sharma" <[EMAIL PROTECTED]> wrote: > > > Hi Jeff, > > > > I think commit 866b04fccbf125cd39f2bdbcfeaa611d39a061a8 was wrong, and > > introduced a regression. > > > > The "relevant" changelog [*] of that patch says: > > > > > > > on filesystems w/o permanent inode numbers, i_ino values can be larger > > > than 32 bits, which can cause problems for some 32 bit userspace programs > > > on a 64 bit kernel. We can't do anything for filesystems that have > > > actual >32-bit inode numbers, but on filesystems that generate i_ino > > > values on the fly, we should try to have them fit in 32 bits. We could > > > trivially fix this by making the static counters in new_inode and iunique > > > 32 bits [...] > > > > > > [...] > > > When a 32-bit program that was not compiled with large file offsets does a > > > stat and gets a st_ino value back that won't fit in the 32 bit field, > > > glibc > > > (correctly) generates an EOVERFLOW error. We can't do anything about fs's > > > with larger permanent inode numbers, but when we generate them on the fly, > > > we ought to try and have them fit within a 32 bit field. > > > > > > This patch takes the first step toward this by making the static counters > > > in these two functions be 32 bits. > > > > > > 1. First and foremost, there was nothing wrong with the existing code that > >needed to be "fixed" at all, i.e. there was no "problem" to be solved in > >the first place. As was said, glibc *correctly* returns EOVERFLOW when a > >userspace application built *without* _FILE_OFFSET_BITS == 64 (i.e. > >ino_t != __ino64_t) tries to stat(2) a file whose serial number does not > >fit in the "st_ino" member of struct stat. This behaviour is (1) correct, > >(2) explicitly mandated by the Single UNIX Specification, and, (3) all > >userspace programs *must* be prepared to deal with it. [ Should probably > >mention here that other implementations, such as Solaris, do conform with > >SUS here. ] > > > > The ideal situation is that everyone would recompile their programs > with LFS defines. Unfortunately people have old userspace programs to > which they don't have sources, or that can't easily be recompiled this way. > These programs would occasionally break when run on 64 bit kernels > for the reasons I've described. That's a bad excuse! Such userspace programs are buggy, period. Let's fix *them*. And, seriously, are you *really* talking of "supporting" userspace programs whose even *sources* are no longer available ? The standard is clear and simple -- calls from userspace programs (that don't define LFS) to stat(2) on a file whose serial number is >2**32 must see EOVERFLOW. This is *not* a kernel problem that needs "fixing". Moreover, changing a kernel function such as iunique() (which was expressly *written* to be used by filesystems to assign ino_t to inodes) to return only values <= 2**32 to satisfy such buggy programs is just ... bad. BTW, you might've as well changed the type of "res" in iunique() in that patch to "unsigned int" too. What's the point of declaring it "ino_t" if we never assign it any value in the (ino_t - unsigned int) set in the first place? > > 2. The patch has nothing to do with "32-bit userspace on 64-bit kernels" or > >compatibility modes whatsoever. It is unrelated and tangential that this > >behaviour is easy to reproduce on the above mentioned setup. Simply put, > >the issue is that a userspace program built *without* LFS tried to > >stat(2) a file with serial number > 2**32. Needless to say, this issue > >must be solved in the userspace program itself (either by (1) defining > >LFS, or, (2) making it aware of EOVERFLOW), and not in the kernel. > > > > It most certainly does have something to do with 32 bit userspace on 64 > bit kernels. No, it doesn't ... > On a 32 bit kernel, new_inode and iunique generate no > inode numbers >32 bits. On a 64 bit kernel, they do. This is *unrelated*. It's completely immaterial how an inode managed to get a serial number > 2**32. Whether it used iunique() running on a 64-bit kernel, or it's own little implementation, or whatever. The *real* issue is with the *userspace program* and not the kernel ... that's the whole point. [ Also, you're assuming sizeof(long) == sizeof(int) for 32-bit kernels here, but okay, probably that's true for all supported targets ... ] > This means that > programs that are built this way may eventually fail on a 64 bit kernel > when the inode counter grows large enough. Those programs will work > indefinitely on a 32 bit kernel. See below, for why such programs are buggy ... > > 3. Solving a problem at a place where it does not exist naturally leads to > >other breakage. After 866b04fccbf125cd, iunique() no longer returns an > >ino_t, but only values <= 2**32, which limits the number of inodes on > >al
Re: Wasting our Freedom
On Sun, Sep 16, 2007 at 06:35:12PM -0700, David Schwartz wrote: > > > On Sun, Sep 16, 2007 at 05:29:56PM -0700, David Schwartz wrote: > > > > >... > > > Again, one more time: > > > > > > 1) You can obtain, from the GPL, the right to remove a BSD > > > license notice. > > >... > > > I hope noone believes this bullshit you are spreading. > > How do you figure? > > > When you incorporate BSD licenced code into a GPL'ed project it's > > impossible that the GPL could give you any permission to remove the > > BSD licence notice. > > That's right. I never said otherwise. I did not say that under all > conceivable circumstances, the GPL gives you the right to remove a BSD > license notice. >... You did say otherwise. Your claim was that "You can obtain, *from the GPL*, the right to remove a BSD license notice." This claim is bullshit. You can get this right from the copyright holder, e.g. when he dual-licenced his code, but you can not get this right from the GPL. > DS cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: Wasting our Freedom
On Sun, Sep 16, 2007 at 09:19:14PM -0400, Theodore Tso wrote: >... > Now, in the case of the Atheros wireless code, the original author > (Sam Leffler) has stated that as far as *his* code was concerned, he > was willing to dual license it. However, in this case, he agreed to > have the code dual-licensed three years after the project was started. > He was amused and had no objections to people retroactively applying > the licensing changes to code that was 3 years old.[1] >... It's actually the other way round: Sam changed the licence from dual 3-clause BSD and GPL to 2-clause BSD. > - Ted cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: Wasting our Freedom
Theodore Tso wrote: Essentially, I agree with you. My only disagremeent with you is that I think the problem starts sooner: > However, consider a file which was originally BSD licensed. Now > suppose it is modified (i.e., a derived work was created) and another > author slaps on a BSD/GPL dual notice. That's fine, so far; the BSD > license on the original file permits that. The new code is licensed > under either BSD or GPL (user's choice), and the original code is > under the BSD license, which is compatible with the GPL code, so > regardless of whether the user choose the BSD or GPL license. I would argue that it's really not so fine so far. You need to careful to make sure that anybody who receives this file understands that they *must* comply with the BSD license in addition to the GPL. There choices are not "BSD or GPL" they are "BSD or BSD+GPL". They may choose to comply with just the terms of the BSD license, or they may choose to in addition require those who make further derivatives to comply with the GPL *as* *well*. But this is not really dual-licensed as you cannot choose just the GPL. DS - 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]PCI:disable resource decode in PCI BAR detection
On Sun, 2007-09-16 at 15:13 +0400, Ivan Kokshaysky wrote: > On Fri, Sep 14, 2007 at 05:53:58PM -0600, Robert Hancock wrote: > > In the first one, Linus talks about a USB controller whose SMM code > > chokes on the BAR being disabled. That explanation seems odd to me. If > > it chokes on the BAR disabled, how doesn't it choke on the BAR being > > moved to a different location, which is unavoidable during probing? > > Here is an article with detailed explanation of that USB issue: > > http://support.microsoft.com/kb/250635 > > The most interesting fact there is that windows *does not* clear > PCI_COMMAND_MEMORY bits during PCI bus enumeration, so BIOS writers > have to rely on that. Yet another reason why your patch is unsafe. > > > Also, I think we do USB handoff from the BIOS much earlier than we used > > to, which likely prevents these issues. > > I don't think so. This can only be done in USB driver, which cannot run > before PCI device discovery. Most BIOS has an option called legacy emulation, which will emulate USB mouse as legacy mouse. BIOS is using USB before driver is loaded. If moving BAR work, disabling BAR should work too. > > In the second one, he mentions that "So the secondary rule to "don't > > turnoff MEM or IO accesses" is "never allocate real PCI BAR resources at > > the top of memory". Well, unfortunately, the second one isn't possible > > to meet given that we have boards with the MMCONFIG up there, so > > disabling the decode is the only thing we can do. That whole discussion > > was also based on the fact that it wasn't necessary to solve problems. > > This is no longer a theoretical problem. We now have real problems that > > we need this in order to solve. > > I have suggested a *practical* solution that disables the decode only > when it's unavoidable. If it's not sufficient for some machines, it > can be extended quite easily. If you just want to workaroud the issue at hand, I'd take the method to not use mmcfg at probe stage. > > > No, it's impossible for several reasons. Most obvious one is that a PCI-E > > > bridge does isolate stuff quite nicely. > > > > It's not impossible at all. In fact I'm quite sure (Jesse can confirm) > > that in the case of the board he was using, it was an add-in graphics > > card where he saw this problem. > > Again, it's impossible with AGP or PCI-E cards, which are always > separated > from the root bus by AGP or PCI-E bridge. The bridge does decode in > the > first place, so when you write the BAR with all ones, you move it > outside > the bridge decoding window. Address collision isn't possible in this > case in principle. I can confirm this is an add-in graphics card. the bfd is 00:02.0, so it's not behind any AGP/PCI-E bridge. Thanks, Shaohua - 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: Wasting our Freedom
> On Sun, Sep 16, 2007 at 05:29:56PM -0700, David Schwartz wrote: > > >... > > Again, one more time: > > > > 1) You can obtain, from the GPL, the right to remove a BSD > > license notice. > >... > I hope noone believes this bullshit you are spreading. How do you figure? > When you incorporate BSD licenced code into a GPL'ed project it's > impossible that the GPL could give you any permission to remove the > BSD licence notice. That's right. I never said otherwise. I did not say that under all conceivable circumstances, the GPL gives you the right to remove a BSD license notice. The example I was talking about was a dual-licensed work. If you choose to make modifications under the GPL, then you are not obtaining any righst under the BSD license and are under no obligation to comply with its terms. In that case, the GPL gives you the right to remove the BSD license notice. (The license remains, of course, only the notice is gone.) You are quite correct in the case of a BSD-only work. Since you still need the right to modify and distribute that work and can only get it from the BSD license, you must comply with the terms of the BSD license. One of those terms is not removing the license *notice*. You are quite correct that if a work is offered under only the BSD license, the BSD license notice must remain in there forever, you cannot remove it because the license says you can't. > > > BTW: It is considered impolite on linux-kernel to remove Cc's. > > > > Really? On almost every other forum I know of, the rule is the > > reverse. It is rude to CC posts to people who are most likely on > > the list anyway. > linux-kernel is not "almost every other forum I know of". > > Considering how long you are already trolling [1] on linux-kernel > I'm surprised you haven't heard about this before. I find offensive your characterization of my attempt at honest debate as trolling. > [1] Have you ever contributed any patch to the Linux kernel? Yes, as a matter of fact. A long time ago, I contributed patches to allow the Sony CDU-535 driver to work as a module. For those who forgot, the Sony CDU-535 was one of the very first CD-ROM devices, almost 1X and with a proprietary interface -- an external drive that required a custom ISA card. For some reason, it's still there, though I find it hard to believe anyone has used it in years. DS - 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] modpost: detect unterminated device id lists
Hi Kees,
On 9/13/07, Kees Cook <[EMAIL PROTECTED]> wrote:
>
> This patch against 2.6.23-rc6 will cause modpost to fail if any device
> id lists are incorrectly terminated, after reporting the offender.
>
> Signed-off-by: Kees Cook <[EMAIL PROTECTED]>
Nice! :-)
BTW a very similar idea (but for a different problem) was discussed in:
http://lkml.org/lkml/2007/8/23/48
I tried doing something about that, but gave up in between. For the
device_id tables, a lot of infrastructure/code already exists in modpost,
but no such luck for kobjects :-( Still, if you can do something about
that, as he mentioned, I bet Greg would gladly accept such a patch :-)
> --- linux-2.6.23-rc6~/scripts/mod/file2alias.c 2007-09-11 23:17:49.0
> -0700
> +++ linux-2.6.23-rc6/scripts/mod/file2alias.c 2007-09-12 17:41:30.0
> -0700
> @@ -55,10 +55,13 @@ do {
> * Check that sizeof(device_id type) are consistent with size of section
> * in .o file. If in-consistent then userspace and kernel does not agree
> * on actual size which is a bug.
> + * Also verify that the final entry in the table is all zeros.
> **/
> -static void device_id_size_check(const char *modname, const char *device_id,
> -unsigned long size, unsigned long id_size)
> +static void device_id_check(const char *modname, const char *device_id,
> + unsigned long size, unsigned long id_size,
> + void *symval)
If you pass the Elf_Sym *sym all the way from handle_moddevtable() (which
means you can get rid of the sym->st_size argument in the call chain), then
it would be possible to print out the *symbol name* too here ...
> {
> + int i;
uint8_t *p;
> if (size % id_size || size < id_size) {
> fatal("%s: sizeof(struct %s_device_id)=%lu is not a modulo "
> "of the size of section __mod_%s_device_table=%lu.\n"
> @@ -66,6 +69,18 @@ static void device_id_size_check(const c
> "in mod_devicetable.h\n",
> modname, device_id, id_size, device_id, size,
> device_id);
> }
> + /* Verify last one is a terminator */
> + for (i = 0; i < id_size; i++ ) {
> + if ( *(uint8_t*)(symval+size-id_size+i) ) {
... and:
for (p = symval+size-id_size; p < symval+size; p++) {
if (*p) {
is probably clearer ?
> + fprintf(stderr,"%s: struct %s_device_id is %lu bytes.
> The last of
> %lu is:\n", modname, device_id, id_size, size / id_size);
As I just said, printing out just the modname and device_id "type" sounds
insufficient here. Note that they were sufficient before your patch, because
previously, this function only checked if the device_id *type* itself was
incorrectly defined. But here we're talking about a specific errant *symbol*.
> + for (i = 0; i < id_size; i++ ) {
> + fprintf(stderr,"0x%02x ",
> *(uint8_t*)(symval+size-id_size+i) );
> + }
Again, "for (p = symval+size-id_size; p < symval+size; p++) {"
and then "fprintf(..., *p);" would be cleaner.
> + fprintf(stderr,"\n");
> + fatal("%s: struct %s_device_id is not terminated "
> + "with a NULL entry!\n", modname, device_id);
Subtle nit, but it's not really a "NULL" entry. It's an "empty object" entry,
not a "NULL" pointer ... how about replacing "a NULL" with "an empty" ?
> + }
> + }
> }
>
> /* USB is special because the bcdDevice can be matched against a numeric
> range */
> @@ -168,7 +183,7 @@ static void do_usb_table(void *symval, u
> unsigned int i;
> const unsigned long id_size = sizeof(struct usb_device_id);
>
> - device_id_size_check(mod->name, "usb", size, id_size);
> + device_id_check(mod->name, "usb", size, id_size, symval);
>
> /* Leave last one: it's the terminator. */
> size -= id_size;
> @@ -505,7 +520,7 @@ static void do_table(void *symval, unsig
> char alias[500];
> int (*do_entry)(const char *, void *entry, char *alias) = function;
>
> - device_id_size_check(mod->name, device_id, size, id_size);
> + device_id_check(mod->name, device_id, size, id_size, symval);
> /* Leave last one: it's the terminator. */
> size -= id_size;
>
> @@ -527,14 +542,22 @@ void handle_moddevtable(struct module *m
> Elf_Sym *sym, const char *symname)
> {
> void *symval;
> + char *zeros = NULL;
>
> /* We're looking for a section relative symbol */
> if (!sym->st_shndx || sym->st_shndx >= info->hdr->e_shnum)
> return;
>
> - symval = (void *)info->hdr
> - + info->sechdrs[sym->st_shndx].sh_offset
> - + sym->st_value;
> + /* Handle all-NULL symbols allocated into .bss */
> + if (info->sec
Re: Wasting our Freedom
On Sun, Sep 16, 2007 at 05:29:56PM -0700, David Schwartz wrote: > In responses and posts, there is over and over a huge confusion > between two completely different issues. One is about whether you > can modify licenses, the other is about whether you can modify > license *notices*. > > Again, one more time: > > 1) You can obtain, from the GPL, the right to remove a BSD license notice. > > 2) You can obtain, from the BSD license, the right to remove a GPL > license notice. > > 3) Neither of these actions has any effect on the fact that these > licenses still exist from the original author and still grant rights > to anyone who comes into lawful possession of the work. > > Of course, if you take a dual-licensed file, remove the BSD notice, > and then add more to it, those contributions can be offered *by* > *their* *original* *authors* under only the GPL. Careful; the devil is really in the details on this one. If you have a file where all of the code was originally dual licensed (say, like drivers/char/random.c, which was written by me and deliberately dual licensed because I wanted other OS's to be able to use it), then this might be true. However, consider a file which was originally BSD licensed. Now suppose it is modified (i.e., a derived work was created) and another author slaps on a BSD/GPL dual notice. That's fine, so far; the BSD license on the original file permits that. The new code is licensed under either BSD or GPL (user's choice), and the original code is under the BSD license, which is compatible with the GPL code, so regardless of whether the user choose the BSD or GPL license. However, in such a case it is **NOT** kosher to remove the BSD license notification. Why? Because the lines of code from the original file was originally licensed under the BSD only. The second author who added the BSD/GPL'ed dual license only has the authority to release the the code which he or she added under the BSD/GPL dual license. The original code remains only licensed under the BSD license, but that was OK because the BSD license is compatible with the GPL (but not vice versa). Now, in the case of the Atheros wireless code, the original author (Sam Leffler) has stated that as far as *his* code was concerned, he was willing to dual license it. However, in this case, he agreed to have the code dual-licensed three years after the project was started. He was amused and had no objections to people retroactively applying the licensing changes to code that was 3 years old.[1] HOWEVER, he can only speak for himself. If anyone in the first 3 years of the project made significant code contributions, they would have reasonably expected them to be made under the BSD license, and Sam's agreement to dual-license his code wouldn't apply to some other major contributor. And if there is any code which was not written by Sam contributed dring the first 3 years, then it could only be distributed under the terms of the BSD license, regardless of Sam's statements. This may be one of the reasons why Eben said that very careful research needs to be done before making any definitive statement on the subject. Personally, my recommendation would just be to include the original copyright statement (removing attribution is bad ju-ju) and also to leave BSD permission statement in place. Yes, maybe after doing a huge amount of research we might be able to determine that all of the code belonged to Sam at the point when he agreed to dual license it, but is it worth it to make 100% sure of this question? Why not just leave the BSD statement in place, and be done with it. We've done this before; for example, take a look at drivers/net/slhc.c as evidence of the fact that we do have some BSD code in the Linux kernel, and having the BSD permission notice really doesn't hurt anyone. [1] http://lkml.org/lkml/2007/9/1/160 - Ted - 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/
printk format "%4.4s"
Hi, all I have a question about printk format. Can printk format use "%4.4s"? This format is used following source. # drivers/acpi/tables/tbinstal.c ACPI_ERROR((AE_INFO, "Table has invalid signature [%4.4s], must be SSDT, PSDT or OEMx", table_desc->pointer->signature)); ## At least, my dmesg is buggy output like that.. ## $ dmesg (snip) ACPI Warning (tbutils-0158): Incorrect checksum in table [ ^E礑 - 00, should b e F6 [20070126] ACPI Error (tbinstal-0134): Table has invalid signature [ ^E礑, must be SSDT, P SDT or OEMx [20070126] (snip) ## - 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: Wasting our Freedom
On Sun, Sep 16, 2007 at 05:29:56PM -0700, David Schwartz wrote: >... > Again, one more time: > > 1) You can obtain, from the GPL, the right to remove a BSD license notice. >... I hope noone believes this bullshit you are spreading. When you incorporate BSD licenced code into a GPL'ed project it's impossible that the GPL could give you any permission to remove the BSD licence notice. > > BTW: It is considered impolite on linux-kernel to remove Cc's. > > Really? On almost every other forum I know of, the rule is the reverse. It is > rude to CC posts to people who are most likely on the list anyway. linux-kernel is not "almost every other forum I know of". Considering how long you are already trolling [1] on linux-kernel I'm surprised you haven't heard about this before. > DS cu Adrian [1] Have you ever contributed any patch to the Linux kernel? -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: Wasting our Freedom
Adrian Bunk writes: > On Sun, Sep 16, 2007 at 03:37:55PM -0700, David Schwartz wrote: > > > Dual licenced code by definition explicitely states that you > > > can choose > > > the licence - otherwise it wouldn't be called dual-licenced. > > You can choose under which license you would like to receive > > the right to modify or distribute the code. But you cannot change > > the license that code itself is covered by. > You can choose the licence under which you distribute the code. This is a misleading statement. When you distribute the code, you can choose from which license you obtain the right to distribute, but this has *NO* effect on the rights the recipient of the code gets. This is a common misunderstanding, so people who understand the issue should work extra hard to be clear. If you obtain the right to distribute a dual-licensed work to me from the GPL, I still receive a dual-license to the work from the original author. You are not a party to the grant and cannot modify it. > It's obvious that everyone else receiving the dual licenced code still > can choose for himself. Everyone receiving dual-licensed code who wishes to modify or distribute that code may choose from which license they obtain that right. They need only comply with the terms of the license from which they obtain rights. But this has no effect on anybody else nor does it have any effect on what rights recipients get to that original work. In every case, a recipient gets from the original author all the rights the original author offered to those elements that person authored. > > Theo is right, you cannot choose the license on _this_ code. > > You can, of course, control the license on code that you > > contribute. Nothing prevents a derivative work from being under a > > different license from the original work. > It would have helped if you would have read the email I gave a link to... > > Theo was saying in his email: > > <-- snip --> > > In http://lkml.org/lkml/2007/8/29/183, Alan Cox managed to summarize > what Jiri Slaby and Luis Rodriguez were trying to do by proposing a > modification of a Dual Licenced file without the consent of all the > authors. Alan asks "So whats the problem ?". Well, Alan, I must > caution you -- your post is advising people to break the law. > > <-- snip --> > > Theo claims quite clearly that removing the BSD licence notice when > modifying BSD/GPL dual licenced code would break the law. In responses and posts, there is over and over a huge confusion between two completely different issues. One is about whether you can modify licenses, the other is about whether you can modify license *notices*. You can obtain the right to modify or remove a BSD license *notice* from the GPL. The GPL gives you the right to modify and doesn't require you to keep any *other* licenses intact. But this is simply a change to a notice. It has no effect on anyone's actual substantive rights whatsoever. To the extent that others are saying that you cannot modify the *license*, they are correct. The original author extended that license to all recipients of their code, regardless of how they get them, and you cannot affect this process in any way. Again, one more time: 1) You can obtain, from the GPL, the right to remove a BSD license notice. 2) You can obtain, from the BSD license, the right to remove a GPL license notice. 3) Neither of these actions has any effect on the fact that these licenses still exist from the original author and still grant rights to anyone who comes into lawful possession of the work. Of course, if you take a dual-licensed file, remove the BSD notice, and then add more to it, those contributions can be offered *by* *their* *original* *authors* under only the GPL. Any protectable elements still in the work that were offered by their original authors under either a dual-license or a BSD license are still licensed to every recipient of that derivative work under the original license. (See GPL section 6 and if you think it through, there's simply no other way it could work.) > BTW: It is considered impolite on linux-kernel to remove Cc's. Really? On almost every other forum I know of, the rule is the reverse. It is rude to CC posts to people who are most likely on the list anyway. DS - 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] modpost: detect unterminated device id lists
On 9/17/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Sep 2007 17:49:37 -0700 Kees Cook <[EMAIL PROTECTED]> wrote:
>
> > This patch against 2.6.23-rc6 will cause modpost to fail if any device
> > id lists are incorrectly terminated, after reporting the offender.
>
> I'm getting this:
>
> rusb2/pvrusb2: struct usb_device_id is 20 bytes. The last of 3 is:
> 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> 0x00 0x00 0x00 0x00 0x00
> FATAL: drivers/media/video/pvrusb2/pvrusb2: struct usb_device_id is not
> terminated
> with a NULL entry!
>
> ("rusb2/pvrusb2" ??)
Hmm? Are you sure you didn't see any "drivers/media/video/pv" before the
"rusb2/pvrusb2" bit? Looking at Kees' patch (and the existing code), I've no
clue how/why this should happen ... will try to reproduce here ...
> but:
>
> struct usb_device_id pvr2_device_table[] = {
> [PVR2_HDW_TYPE_29XXX] = { USB_DEVICE(0x2040, 0x2900) },
> [PVR2_HDW_TYPE_24XXX] = { USB_DEVICE(0x2040, 0x2400) },
> { USB_DEVICE(0, 0) },
> };
>
> looks OK?
>
> Using plain old "{ }" shut the warning up.
USB_DEVICE(0, 0) is not empty termination, actually, and this looks like
a genuine bug caught by the patch. As that dump shows, USB_DEVICE(0, 0)
assigns "0x03 0x00" (in little endian) to usb_device_id.match_flags. And
I don't think the USB code treats such an entry as an empty entry (?)
Interestingly, the "USB_DEVICE(0, 0)" thing is absent from latest -git
tree and also in my copy of 23-rc4-mm1 -- so this looks like something
you must've merged recently.
-
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]PCI:disable resource decode in PCI BAR detection
On Sun, 2007-09-16 at 17:37 -0600, Robert Hancock wrote: > We would already have this problem, though. If it causes problems to > disable decode on the BAR because we try to access it in interrupt > context, we would already have problems because we move the thing to > 0x during probing anyway.. Yes, it's not a new problem, I was just pointing out the fact that there are deeper issues already there in the same area. Today, we mostly get lucky because we rarely take an irq during boot time PCI probe but I've seen it happen (one easy way to screw things up on -many- machines is to enable the DEBUG stuff in the PCI probe code and use a serial console for example, especially if access to the device with the serial ports in it gets temporarily cut off). Cheers, 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: Wasting our Freedom
[EMAIL PROTECTED] wrote: you claim that it's unethical for the linux community to use the code, but brag about NetApp useing the code. what makes NetApp ok and Linux evil? many people honestly don't understand the logic behind this. please explain it. There are two highly relevant angles to this that nobody is mentioning: 1) Does it make sense to share code, at a technical level? The fact is, BSD and Linux wireless stacks are quite different. Linux also has a technical requirement that "Linux drivers look like Linux drivers." This enables a vast array of source code checking tools like Coverity and sparse, as well as maximizing human reviewer bandwidth. Therefore, there is a strong /technical/ motivation for the source code to diverge. That's quite natural. 2) Information sharing is both rampant and healthy. Linux and BSD projects share a vast amount of hardware knowledge, information on how to properly program hardware. Linux folks use BSD code as /reference documentation/, and BSD folks do the same with Linux code. This is far more efficient in many cases, due to the natural divergence of the respective codebases. It is often easier to look at codebase A, and then mentally translate that into code for codebase B, than to directly copy and reuse code. 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: iunique() fails to return ino_t (after commit 866b04fccbf125cd)
On Mon, 17 Sep 2007 00:58:54 +0530 "Satyam Sharma" <[EMAIL PROTECTED]> wrote: > Hi Jeff, > > I think commit 866b04fccbf125cd39f2bdbcfeaa611d39a061a8 was wrong, and > introduced a regression. > > The "relevant" changelog [*] of that patch says: > > > > on filesystems w/o permanent inode numbers, i_ino values can be larger > > than 32 bits, which can cause problems for some 32 bit userspace programs > > on a 64 bit kernel. We can't do anything for filesystems that have > > actual >32-bit inode numbers, but on filesystems that generate i_ino > > values on the fly, we should try to have them fit in 32 bits. We could > > trivially fix this by making the static counters in new_inode and iunique > > 32 bits [...] > > > > [...] > > When a 32-bit program that was not compiled with large file offsets does a > > stat and gets a st_ino value back that won't fit in the 32 bit field, glibc > > (correctly) generates an EOVERFLOW error. We can't do anything about fs's > > with larger permanent inode numbers, but when we generate them on the fly, > > we ought to try and have them fit within a 32 bit field. > > > > This patch takes the first step toward this by making the static counters > > in these two functions be 32 bits. > > > 1. First and foremost, there was nothing wrong with the existing code that >needed to be "fixed" at all, i.e. there was no "problem" to be solved in >the first place. As was said, glibc *correctly* returns EOVERFLOW when a >userspace application built *without* _FILE_OFFSET_BITS == 64 (i.e. >ino_t != __ino64_t) tries to stat(2) a file whose serial number does not >fit in the "st_ino" member of struct stat. This behaviour is (1) correct, >(2) explicitly mandated by the Single UNIX Specification, and, (3) all >userspace programs *must* be prepared to deal with it. [ Should probably >mention here that other implementations, such as Solaris, do conform with >SUS here. ] > The ideal situation is that everyone would recompile their programs with LFS defines. Unfortunately people have old userspace programs to which they don't have sources, or that can't easily be recompiled this way. These programs would occasionally break when run on 64 bit kernels for the reasons I've described. > 2. The patch has nothing to do with "32-bit userspace on 64-bit kernels" or >compatibility modes whatsoever. It is unrelated and tangential that this >behaviour is easy to reproduce on the above mentioned setup. Simply put, >the issue is that a userspace program built *without* LFS tried to >stat(2) a file with serial number > 2**32. Needless to say, this issue >must be solved in the userspace program itself (either by (1) defining >LFS, or, (2) making it aware of EOVERFLOW), and not in the kernel. > It most certainly does have something to do with 32 bit userspace on 64 bit kernels. On a 32 bit kernel, new_inode and iunique generate no inode numbers >32 bits. On a 64 bit kernel, they do. This means that programs that are built this way may eventually fail on a 64 bit kernel when the inode counter grows large enough. Those programs will work indefinitely on a 32 bit kernel. > 3. Solving a problem at a place where it does not exist naturally leads to >other breakage. After 866b04fccbf125cd, iunique() no longer returns an >ino_t, but only values <= 2**32, which limits the number of inodes on >all filesystems that use that function. Needless to say, this is a >*regression* w.r.t. previous kernels before that commit went in. > Why is this a problem? Filesystems that truly need that many more inodes are certainly able to generate one using a different scheme. Typically, the inode numbers generated by iunique and new_inode are only used by filesystems that have no permanent inode numbers of their own. In many cases, inode number uniqueness isn't even an issue as evidenced by the number of filesystems that simply use the number assigned by new_inode. This patch seems like a reasonable compromise to me. It allows us to keep these inode numbers below 32 bits on filesystems that don't care too much about what inode number they're using. > 4. Last but not the least, the sample testcase program that was discussed >on LKML last year to show this "problem" was buggy and wrong. A program >built without LFS will also suffer EOVERFLOW when stat(2)'ing a file >due to other reasons, such as filesize not fitting inside the "st_size" >member. Do we propose to "fix" that "problem" in the kernel too ? >Of course not! > Right, but that situation is the same regardless of whether you run it on a 32 or 64 bit kernel. The issue of inode numbers generated by new_inode and iunique crossing the 32-bit boundary, however, is not. Can you elaborate why this testcase was buggy and wrong? It seems to me that it correctly demonstrated the issue. Just because there are other reasons that a program might get an EOVERFLOW doesn't mean th
Re: Wasting our Freedom
On Sun, 16 Sep 2007, Jacob Meuser wrote: On Sun, Sep 16, 2007 at 05:12:08PM -0400, Theodore Tso wrote: reimplement them. Why don't you go and try asking NetApp for sources to WAFL, and claim that they have "moral" duty to give the code back, and see how quickly you get laughed out of the office? which is _exactly_ what you guys are doing. so the linux community is morally equivilent to a corporation? that's what it sounds like you are all legally satisfied with. if it's legal it's legal. it's not a matter of the Linux community being satisfied eith it, it's a matter of the BSD people desiring it based on their selection of license (and the repeated statements that this feature of the BSD license being an advantage compared to the GPL makes it clear that this isn't an unknown side effect, it's an explicit desire). so the Linux community is following the desires of the BSD community by following their license but the BSD community is unhappy, why? you claim that it's unethical for the linux community to use the code, but brag about NetApp useing the code. what makes NetApp ok and Linux evil? many people honestly don't understand the logic behind this. please explain it. if you don't like what your license allows, change it. it's trivial for you to do so, all you need to do is to agree on a new license and start releaseing your code under it (the BSD license allows for derivitive works to be released under any license) make the new license match your real desires and this sort of problem can be avoided in the future. David Lang - 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] net/: all net/ cleanup with ARRAY_SIZE
From: Denis Cheng <[EMAIL PROTECTED]> Date: Sun, 2 Sep 2007 18:30:17 +0800 > Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> You already submitted the net/ipv4/af_inet.c case seperately, so I had to remove it from this patch for it to apply properly. Please keep your patches straight to avoid problems like this. Thans. - 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] net/ipv4/af_inet.c: use ARRAY_SIZE macro from kernel.h instead
From: Denis Cheng <[EMAIL PROTECTED]> Date: Sun, 2 Sep 2007 12:59:07 +0800 > Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> Applied to net-2.6.24, thanks! - 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/3] netlink: use a statically allocated nl_table instead
From: Denis Cheng <[EMAIL PROTECTED]> Date: Sun, 2 Sep 2007 03:45:59 +0800 > if the table is always fixed size with MAX_LINKS entries, why not use a > statically > allocated table straightforwardly? > > Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> I made the explicit decision to dynamically allocate because many systems have limits on how large the kernel image can be and therefore the less we statically allocate huge tables (constant size or not) the better. Lockdep is the worst offender, for example, it's completely awful. It consumes 4MB of kernel BSS space when enabled on a 64-bit platform. Patch not 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]PCI:disable resource decode in PCI BAR detection
Benjamin Herrenschmidt wrote: On Thu, 2007-09-13 at 21:32 -0600, Robert Hancock wrote: If we do encounter other devices that choke on having the BAR disabled during probing then we can add additional quirk logic, but we haven't run into anything like that yet. Well... if the device needs to be accessed to service an interrupt then you do have a problem. For example... the PIC :-) Problem is.. it's not practical nor really feasible generally to have IRQs off on all CPUs during PCI probing neither... Unless we define that the initial boot time probing is "special", and the first pass that actually probes devices (and doesn't muck around with the sysfs hierarchy etc...) can be run in a special context with all interrupt servicing disabled on the PIC, though that will require some arch support. Ben. We would already have this problem, though. If it causes problems to disable decode on the BAR because we try to access it in interrupt context, we would already have problems because we move the thing to 0x during probing anyway.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] netlink: the temp variable name max is ambiguous
From: Denis Cheng <[EMAIL PROTECTED]>
Date: Sun, 2 Sep 2007 03:45:58 +0800
> with the macro max provided by , so changed its name to a
> more proper one: limit
>
> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
Not strictly necessary because CPP knows to differentiate between
'max(' and plain 'max' when evaluating if a CPP macro should be
expanded or not.
Nonetheless, applied to net-2.6.24, thanks.
-
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/3] netlink: use the macro min(x,y) provided by instead
From: Denis Cheng <[EMAIL PROTECTED]> Date: Sun, 2 Sep 2007 03:45:57 +0800 > Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> Applied to net-2.6.24, thanks. - 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: Wasting our Freedom
On Sun, Sep 16, 2007 at 05:12:08PM -0400, Theodore Tso wrote: > reimplement them. Why don't you go and try asking NetApp for sources > to WAFL, and claim that they have "moral" duty to give the code back, > and see how quickly you get laughed out of the office? which is _exactly_ what you guys are doing. so the linux community is morally equivilent to a corporation? that's what it sounds like you are all legally satisfied with. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org - 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: Wasting our Freedom
On Sun, Sep 16, 2007 at 03:37:55PM -0700, David Schwartz wrote: > > > Dual licenced code by definition explicitely states that you can choose > > the licence - otherwise it wouldn't be called dual-licenced. > > You can choose under which license you would like to receive the right to > modify or distribute the code. But you cannot change the license that code > itself is covered by. You can choose the licence under which you distribute the code. It's obvious that everyone else receiving the dual licenced code still can choose for himself. > > Theo claimed it would "break the law" [1] to choose the GPL for > > _this_ code. [2] > > He is quite right. You cannot choose the license under which someone else's > code is offered. It would "break the law" not in the sense that you would be > breaking the law, in the sense that it's impossible because the law does not > allow it. > > You can, however, remove the BSD license notice if you'd like. While the BSD > license prohibits you from removing it, you may choose to obtain the right to > remove it from the GPL. The GPL does not prohibit removing a BSD license and > explicitly grants you the right to make all modifications that it does not > prohibit. > > Note that this removal has no effect on the license on the original code. > > Theo is right, you cannot choose the license on _this_ code. You can, of > course, control the license on code that you contribute. Nothing prevents a > derivative work from being under a different license from the original work. It would have helped if you would have read the email I gave a link to... Theo was saying in his email: <-- snip --> In http://lkml.org/lkml/2007/8/29/183, Alan Cox managed to summarize what Jiri Slaby and Luis Rodriguez were trying to do by proposing a modification of a Dual Licenced file without the consent of all the authors. Alan asks "So whats the problem ?". Well, Alan, I must caution you -- your post is advising people to break the law. <-- snip --> Theo claims quite clearly that removing the BSD licence notice when modifying BSD/GPL dual licenced code would break the law. > DS cu Adrian BTW: It is considered impolite on linux-kernel to remove Cc's. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [00/41] Large Blocksize Support V7 (adds memmap support)
Andrea Arcangeli <[EMAIL PROTECTED]> writes: > You ignore one other bit, when "/usr/bin/free" says 1G is free, with > config-page-shift it's free no matter what, same goes for not mlocked > cache. With variable order page cache, /usr/bin/free becomes mostly a > lie as long as there's no 4k fallback (like fsblock). % free total used free sharedbuffers cached Mem: 13987841372956 25828 0 225224 321504 -/+ buffers/cache: 826228 572556 Swap: 1048568 201048548 When has free ever given any usefull "free" number? I can perfectly fine allocate another gigabyte of memory despide free saing 25MB. But that is because I know that the buffer/cached are not locked in. On the other hand 1GB can instantly vanish when I start a xen domain and anything relying on the free value would loose. The only sensible thing for an application concerned with swapping is to whatch the swapping and then reduce itself. Not the amount free. Although I wish there were some kernel interface to get a preasure value of how valuable free pages would be right now. I would like that for fuse so a userspace filesystem can do caching without cripling the kernel. MfG Goswin - 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: [00/41] Large Blocksize Support V7 (adds memmap support)
[EMAIL PROTECTED] (Mel Gorman) writes: > On (16/09/07 17:08), Andrea Arcangeli didst pronounce: >> zooming in I see red pixels all over the squares mized with green >> pixels in the same square. This is exactly what happens with the >> variable order page cache and that's why it provides zero guarantees >> in terms of how much ram is really "free" (free as in "available"). >> > > This picture is not grouping pages by mobility so that is hardly a > suprise. This picture is not running grouping pages by mobility. This is > what the normal kernel looks like. Look at the videos in > http://www.skynet.ie/~mel/anti-frag/2007-02-28 and see how list-based > compares to vanilla. These are from February when there was less control > over mixing blocks than there is today. > > In the current version mixing occurs in the lower blocks as much as possible > not the upper ones. So there are a number of mixed blocks but the number is > kept to a minimum. > > The number of mixed blocks could have been enforced as 0, but I felt it was > better in the general case to fragment rather than regress performance. > That may be different for large blocks where you will want to take the > enforcement steps. I agree that 0 is a bad value. But so is infinity. There should be some mixing but not a lot. You say "kept to a minimum". Is that actively done or already happens by itself. Hopefully the later which would be just splendid. >> With config-page-shift mmap works on 4k chunks but it's always backed >> by 64k or any other largesize that you choosed at compile time. And if But would mapping a random 4K page out of a file then consume 64k? That sounds like an awfull lot of internal fragmentation. I hope the unaligned bits and pices get put into a slab or something as you suggested previously. >> the virtual alignment of mmap matches the physical alignment of the >> physical largepage and is >= PAGE_SIZE (software PAGE_SIZE I mean) we >> could use the 62nd bit of the pte to use a 64k tlb (if future cpus >> will allow that). Nick also suggested to still set all ptes equal to >> make life easier for the tlb miss microcode. It is too bad that existing amd64 CPUs only allow such large physical pages. But it kind of makes sense to cut away a full level or page tables for the next bigger size each. >> > big you can make it. I don't think my system with 1GB ram would work >> > so well with 2MB order 0 pages. But I wasn't refering to that but to >> > the picture. >> >> Sure! 2M is sure way excessive for a 1G system, 64k most certainly >> too, of course unless you're running a db or a multimedia streaming >> service, in which case it should be ideal. rtorrent, Xemacs/gnus, bash, xterm, zsh, make, gcc, galeon and the ocasional mplayer. I would mostly be concerned how rtorrents totaly random access of mmapped files negatively impacts such a 64k page system. MfG Goswin - 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: [00/41] Large Blocksize Support V7 (adds memmap support)
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Sun, 16 Sep 2007, Jörn Engel wrote: >> >> My approach is to have one for mount points and ramfs/tmpfs/sysfs/etc. >> which are pinned for their entire lifetime and another for regular >> files/inodes. One could take a three-way approach and have >> always-pinned, often-pinned and rarely-pinned. >> >> We won't get never-pinned that way. > > That sounds pretty good. The problem, of course, is that most of the time, > the actual dentry allocation itself is done before you really know which > case the dentry will be in, and the natural place for actually giving the > dentry lifetime hint is *not* at "d_alloc()", but when we "instantiate" > it with d_add() or d_instantiate(). > > But it turns out that most of the filesystems we care about already use a > special case of "d_add()" that *already* replaces the dentry with another > one in some cases: "d_splice_alias()". > > So I bet that if we just taught "d_splice_alias()" to look at the inode, > and based on the inode just re-allocate the dentry to some other slab > cache, we'd already handle a lot of the cases! > > And yes, you'd end up with the reallocation overhead quite often, but at > least it would now happen only when filling in a dentry, not in the > (*much* more critical) cached lookup path. > > Linus You would only get it for dentries that live long (or your prediction is awfully wrong) and then the reallocation amortizes over time if you will. :) MfG Goswin - 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: [00/41] Large Blocksize Support V7 (adds memmap support)
On Mon, 17 September 2007 00:06:24 +0200, Goswin von Brederlow wrote: > > How probable is it that the dentry is needed again? If you copy it and > it is not needed then you wasted time. If you throw it out and it is > needed then you wasted time too. Depending on the probability one of > the two is cheaper overall. Idealy I would throw away dentries that > haven't been accessed recently and copy recently used ones. > > How much of a systems ram is spend on dentires? How much on task > structures? Does anyone have some stats on that? If it is <10% of the > total ram combined then I don't see much point in moving them. Just > keep them out of the way of users memory so the buddy system can work > effectively. As usual, the answer is "it depends". I've had up to 600MB in dentry and inode slabs on a 1GiB machine after updatedb. This machine currently has 13MB in dentries, which seems to be reasonable for my purposes. Jörn -- Audacity augments courage; hesitation, fear. -- Publilius Syrus - 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: sysfs: spit a warning to users when they try to create a duplicate sysfs file
On Fri, Sep 14, 2007 at 02:06:21PM +0200, Cornelia Huck wrote:
> On Thu, 13 Sep 2007 16:41:18 -0700,
> Greg KH <[EMAIL PROTECTED]> wrote:
>
>
> > int sysfs_add_one(struct sysfs_addrm_cxt *acxt, struct sysfs_dirent *sd)
> > {
> > - if (sysfs_find_dirent(acxt->parent_sd, sd->s_name))
> > + if (sysfs_find_dirent(acxt->parent_sd, sd->s_name)) {
> > + printk(KERN_WARNING, "sysfs: duplicate filename '%s' "
>
> Stray ',' here --->^
Ugh, I suck :(
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: [RFC PATCH] SCSI: split Kconfig menu into two
On Sat, Sep 15, 2007 at 06:23:13PM +0200, Adrian Bunk wrote: > > @Greg: > Do you have any numbers regarding how your "Linux Kernel in a Nutshell" > is selling? It is selling reasonably well for an O'Reilly book from what I have been told. But I have not seen any real numbers yet. > Even download numbers? The downloads are spread around all of the kernel.org mirrors so I have absolutely no idea what they are. Nor do I really want to, as it doesn't matter to me. 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: Wasting our Freedom
> Dual licenced code by definition explicitely states that you can choose > the licence - otherwise it wouldn't be called dual-licenced. You can choose under which license you would like to receive the right to modify or distribute the code. But you cannot change the license that code itself is covered by. > Theo claimed it would "break the law" [1] to choose the GPL for > _this_ code. [2] He is quite right. You cannot choose the license under which someone else's code is offered. It would "break the law" not in the sense that you would be breaking the law, in the sense that it's impossible because the law does not allow it. You can, however, remove the BSD license notice if you'd like. While the BSD license prohibits you from removing it, you may choose to obtain the right to remove it from the GPL. The GPL does not prohibit removing a BSD license and explicitly grants you the right to make all modifications that it does not prohibit. Note that this removal has no effect on the license on the original code. Theo is right, you cannot choose the license on _this_ code. You can, of course, control the license on code that you contribute. Nothing prevents a derivative work from being under a different license from the original work. DS - 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: [00/41] Large Blocksize Support V7 (adds memmap support)
[EMAIL PROTECTED] (Mel Gorman) writes: > On (15/09/07 02:31), Goswin von Brederlow didst pronounce: >> Mel Gorman <[EMAIL PROTECTED]> writes: >> >> > On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote: >> >> Nick Piggin <[EMAIL PROTECTED]> writes: >> >> >> >> > In my attack, I cause the kernel to allocate lots of unmovable >> >> > allocations >> >> > and deplete movable groups. I theoretically then only need to keep a >> >> > small number (1/2^N) of these allocations around in order to DoS a >> >> > page allocation of order N. >> >> >> >> I'm assuming that when an unmovable allocation hijacks a movable group >> >> any further unmovable alloc will evict movable objects out of that >> >> group before hijacking another one. right? >> >> >> > >> > No eviction takes place. If an unmovable allocation gets placed in a >> > movable group, then steps are taken to ensure that future unmovable >> > allocations will take place in the same range (these decisions take >> > place in __rmqueue_fallback()). When choosing a movable block to >> > pollute, it will also choose the lowest possible block in PFN terms to >> > steal so that fragmentation pollution will be as confined as possible. >> > Evicting the unmovable pages would be one of those expensive steps that >> > have been avoided to date. >> >> But then you can have all blocks filled with movable data, free 4K in >> one group, allocate 4K unmovable to take over the group, free 4k in >> the next group, take that group and so on. You can end with 4k >> unmovable in every 64k easily by accident. >> > > As the mixing takes place at the lowest possible block, it's > exceptionally difficult to trigger this. Possible, but exceptionally > difficult. Why is it difficult? When user space allocates memory wouldn't it get it contiously? I mean that is one of the goals, to use larger continious allocations and map them with a single page table entry where possible, right? And then you can roughly predict where an munmap() would free a page. Say the application does map a few GB of file, uses madvice to tell the kernel it needs a 2MB block (to get a continious 2MB chunk mapped), waits for it and then munmaps 4K in there. A 4k hole for some unmovable object to fill. If you can then trigger the creation of an unmovable object as well (stat some file?) and loop you will fill the ram quickly. Maybe it only works in 10% but then you just do it 10 times as often. Over long times it could occur naturally. This is just to demonstrate it with malice. > As I have stated repeatedly, the guarantees can be made but potential > hugepage allocation did not justify it. Large blocks might. > >> There should be a lot of preassure for movable objects to vacate a >> mixed group or you do get fragmentation catastrophs. > > We (Andy Whitcroft and I) did implement something like that. It hooked into > kswapd to clean mixed blocks. If the caller could do the cleaning, it > did the work instead of kswapd. Do you have a graphic like http://www.skynet.ie/~mel/anti-frag/2007-02-28/page_type_distribution.jpg for that case? >> Looking at my >> little test program evicting movable objects from a mixed group should >> not be that expensive as it doesn't happen often. > > It happens regularly if the size of the block you need to keep clean is > lower than min_free_kbytes. In the case of hugepages, that was always > the case. That assumes that the number of groups allocated for unmovable objects will continiously grow and shrink. I'm assuming it will level off at some size for long times (hours) under normal operations. There should be some buffering of a few groups to be held back in reserve when it shrinks to prevent the scenario that the size is just at a group boundary and always grows/shrinks by 1 group. >> The cost of it >> should be freeing some pages (or finding free ones in a movable group) >> and then memcpy. > > Freeing pages is not cheap. Copying pages is cheaper but not cheap. To copy you need a free page as destination. Thats all I ment. Hopefully there will always be a free one and the actual freeing is done asynchronously from the copying. >> So if >> you evict movable objects from mixed group when needed all the >> pagetable pages would end up in the same mixed group slowly taking it >> over completly. No fragmentation at all. See how essential that >> feature is. :) >> > > To move pages, there must be enough blocks free. That is where > min_free_kbytes had to come in. If you cared only about keeping 64KB > chunks free, it makes sense but it didn't in the context of hugepages. I'm more concerned with keeping the little unmovable things out of the way. Those are the things that will fragment the memory and prevent any huge pages to be available even with moving other stuff out of the way. It would also already be a big plus to have 64k continious chunks for many operations. Guaranty that the filesystem and block layers can always get such a page (by means of copyin
Re: [00/41] Large Blocksize Support V7 (adds memmap support)
Jörn Engel <[EMAIL PROTECTED]> writes: > On Sun, 16 September 2007 00:30:32 +0200, Andrea Arcangeli wrote: >> >> Movable? I rather assume all slab allocations aren't movable. Then >> slab defrag can try to tackle on users like dcache and inodes. Keep in >> mind that with the exception of updatedb, those inodes/dentries will >> be pinned and you won't move them, which is why I prefer to consider >> them not movable too... since there's no guarantee they are. > > I have been toying with the idea of having seperate caches for pinned > and movable dentries. Downside of such a patch would be the number of > memcpy() operations when moving dentries from one cache to the other. > Upside is that a fair amount of slab cache can be made movable. > memcpy() is still faster than reading an object from disk. How probable is it that the dentry is needed again? If you copy it and it is not needed then you wasted time. If you throw it out and it is needed then you wasted time too. Depending on the probability one of the two is cheaper overall. Idealy I would throw away dentries that haven't been accessed recently and copy recently used ones. How much of a systems ram is spend on dentires? How much on task structures? Does anyone have some stats on that? If it is <10% of the total ram combined then I don't see much point in moving them. Just keep them out of the way of users memory so the buddy system can work effectively. > Most likely the current reaction to such a patch would be to shoot it > down due to overhead, so I didn't pursue it. All I have is an old patch > to seperate never-cached from possibly-cached dentries. It will > increase the odds of freeing a slab, but provide no guarantee. > > But the point here is: dentries/inodes can be made movable if there are > clear advantages to it. Maybe they should? > > Jörn MfG Goswin - 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: Wasting our Freedom
> JFTR, I do *not* think that that assessment was questionable. Unless the > dual-licensing *explicitly* allows relicensing, relicensing is forbidden > by copyright law. The dual-licensing allows relicensing only if that's > *explicitly* stated, either in the statement offering the alternative, or > in one of the licenses. > > Neither GPL nor BSD/ISC allow relicensing in their well-known wordings. > > If you think that's questionable, you should at least provide arguments > (and be ready to have your interpretation of the law and the licenses > tested before court). Nobody is relicensing anything, ever. If the author licenses a work under the GPL only, then that is forever how that work is licensed. If an author licenses a work under the BSD, then that is forever how that work is licensed. Same for a dual license. This applies until the copyright expires or the author offers the code under some other license. Nobody ever relicenses anything, ever. If I give you a copy of a work covered by the GPL, the BSD, a dual-license, or whatever, you get a license to every protectable element in that work from the original author of that element. Nobody ever relicenses anything, ever. Nobody ever modifies anybody else's license, ever. If you take work that's under a dual-license and remove one license notice from it when you create a derivative work, every recipient of that derivative work still receives a dual license from the original author to every protectable element still in the distributed work. The GPL is explicit about this in section 6. The BSD license is not, but it's the only way such a license could work. There are really only two ways you can screw up. 1) You can take GPL-only bits and put them in BSD or dual-licensed code. (The GPL prohibits this.) 2) You can remove a BSD license notice from BSD-only code. (The BSD license prohibits this.) DS - 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] modpost: detect unterminated device id lists
On Wed, 12 Sep 2007 17:49:37 -0700 Kees Cook <[EMAIL PROTECTED]> wrote:
> This patch against 2.6.23-rc6 will cause modpost to fail if any device
> id lists are incorrectly terminated, after reporting the offender.
I'm getting this:
rusb2/pvrusb2: struct usb_device_id is 20 bytes. The last of 3 is:
0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
FATAL: drivers/media/video/pvrusb2/pvrusb2: struct usb_device_id is not
terminated with a NULL entry!
("rusb2/pvrusb2" ??)
but:
struct usb_device_id pvr2_device_table[] = {
[PVR2_HDW_TYPE_29XXX] = { USB_DEVICE(0x2040, 0x2900) },
[PVR2_HDW_TYPE_24XXX] = { USB_DEVICE(0x2040, 0x2400) },
{ USB_DEVICE(0, 0) },
};
looks OK?
Using plain old "{ }" shut the warning up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [00/41] Large Blocksize Support V7 (adds memmap support)
[EMAIL PROTECTED] (Mel Gorman) writes: > On (15/09/07 14:14), Goswin von Brederlow didst pronounce: >> Andrew Morton <[EMAIL PROTECTED]> writes: >> >> > On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote: >> > >> >> While I agree with your concern, those numbers are quite silly. The >> >> chances of 99.8% of pages being free and the remaining 0.2% being >> >> perfectly spread across all 2MB large_pages are lower than those of SHA1 >> >> creating a collision. >> > >> > Actually it'd be pretty easy to craft an application which allocates seven >> > pages for pagecache, then one for , then seven for pagecache, >> > then >> > one for , etc. >> > >> > I've had test apps which do that sort of thing accidentally. The result >> > wasn't pretty. >> >> Except that the applications 7 pages are movable and the >> would have to be unmovable. And then they should not share the same >> memory region. At least they should never be allowed to interleave in >> such a pattern on a larger scale. >> > > It is actually really easy to force regions to never share. At the > moment, there is a fallback list that determines a preference for what > block to mix. > > The reason why this isn't enforced is the cost of moving. On x86 and > x86_64, a block of interest is usually 2MB or 4MB. Clearing out one of > those pages to prevent any mixing would be bad enough. On PowerPC, it's > potentially 16MB. On IA64, it's 1GB. > > As this was fragmentation avoidance, not guarantees, the decision was > made to not strictly enforce the types of pages within a block as the > cost cannot be made back unless the system was making agressive use of > large pages. This is not the case with Linux. I don't say the group should never be mixed. The movable objects could be moved out on demand. If 64k get allocated then up to 64k get moved. That would reduce the impact as the kernel does not hang while it moves 2MB or even 1GB. It also allows objects to be freed and the space reused in the unmovable and mixed groups. There could also be a certain number or percentage of mixed groupd be allowed to further increase the chance of movable objects freeing themself from mixed groups. But when you already have say 10% of the ram in mixed groups then it is a sign the external fragmentation happens and some time should be spend on moving movable objects. >> The only way a fragmentation catastroph can be (proovable) avoided is >> by having so few unmovable objects that size + max waste << ram >> size. The smaller the better. Allowing movable and unmovable objects >> to mix means that max waste goes way up. In your example waste would >> be 7*size. With 2MB uper order limit it would be 511*size. >> >> I keep coming back to the fact that movable objects should be moved >> out of the way for unmovable ones. Anything else just allows >> fragmentation to build up. >> > > This is easily achieved, just really really expensive because of the > amount of copying that would have to take place. It would also compel > that min_free_kbytes be at least one free PAGEBLOCK_NR_PAGES and likely > MIGRATE_TYPES * PAGEBLOCK_NR_PAGES to reduce excessive copying. That is > a lot of free memory to keep around which is why fragmentation avoidance > doesn't do it. In your sample graphics you had 1152 groups. Reserving a few of those doesnt sound too bad. And how many migrate types do we talk about. So far we only had movable and unmovable. I would split unmovable into short term (caches, I/O pages) and long term (task structures, dentries). Reserving 6 groups for schort term unmovable and long term unmovable would be 1% of ram in your situation. Maybe instead of reserving one could say that you can have up to 6 groups of space not used by unmovable objects before aggressive moving starts. I don't quite see why you NEED reserving as long as there is enough space free alltogether in case something needs moving. 1 group worth of space free might be plenty to move stuff too. Note that all the virtual pages can be stuffed in every little free space there is and reassembled by the MMU. There is no space lost there. But until one tries one can't say. MfG Goswin PS: How do allocations pick groups? Could one use the oldest group dedicated to each MIGRATE_TYPE? Or lowest address for unmovable and highest address for movable? Something to better keep the two out of each other way. - 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: + net-sched-sch_cbqc-shut-up-uninitialized-variable.patch added to -mm tree
From: [EMAIL PROTECTED] Date: Thu, 13 Sep 2007 00:25:36 -0700 > From: Satyam Sharma <[EMAIL PROTECTED]> > > net/sched/sch_cbq.c: In function 'cbq_enqueue': > net/sched/sch_cbq.c:383: warning: 'ret' may be used uninitialized in this > function > > has been verified to be a bogus case. So let's shut it up. > > Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> > Acked-by: Patrick McHardy <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Applied to net-2.6, thanks! - 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: + pktgen-srcmac-fix.patch added to -mm tree
From: [EMAIL PROTECTED] Date: Thu, 13 Sep 2007 00:20:13 -0700 > Subject: Pktgen srcmac fix > From: "Adit Ranadive" <[EMAIL PROTECTED]> > > Cc: Jamal Hadi Salim <[EMAIL PROTECTED]> > Cc: "David S. Miller" <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> I've applied this patch to net-2.6, thanks! - 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 video mode patch review
On Sunday, 16 September 2007 22:59, Pavel Machek wrote: > Hi! > > > > Many thanks for taking care of this! > > > > > > We already have a patch in -mm, s2ram-kill-old-debugging-junk.patch from > > > Pavel > > > (http://marc.info/?l=linux-mm-commits&m=118737955611331&w=1), that > > > removes the > > > #ifdefed blocks and it clashes with your first patch a bit. > > > > > > FYI, I have rebased your first patch on top of the Pavel's patch: > > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc6/patches/39-acpi-video-mode-fix.patch > > > > > > > Thanks Rafael, > > > > However, I need to send something upstream to Linus for this kernel > > cycle, so I don't want to base it on an -mm patch. There are two > > alternatives, obviously: 1. send my patch in now based on the "change as > > little as necessary to fix the immediate problem" and then rebase > > Pavel's patch on top of mine, or 2. for me to send both Pavel's patch > > and the rebased patch upstream. > > > > Personally, I would prefer to avoid strategy 2 at this late stage in the > > 2.6.23-rc series. > > Agreed we should have the fix in 2.6.23... Actually doing 2 does not > seem like a big problem, my patch is pretty straight cleanup (and may > even fix some machines, as we avoid touching video ram)... But > resolving conflict is not hard, either; I know, I did it :-). OK, let's take path 1, then. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove an unused variable from the Intel I/OAT DMA engine driver
From: Jesper Juhl <[EMAIL PROTECTED]> Date: Sun, 16 Sep 2007 23:31:50 +0200 > > The 'u16 chanctrl' variable in > drivers/dma/ioatdma.c::ioat_dma_free_chan_resources() is completely > unused and gcc quite rightfully warns about it: > > drivers/dma/ioatdma.c:247: warning: unused variable 'chanctrl' > > This patch removes the unused variable and silences the warning. > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Applied to net-2.6.24, thanks Jesper. - 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] Remove an unused variable from the Intel I/OAT DMA engine driver
The 'u16 chanctrl' variable in drivers/dma/ioatdma.c::ioat_dma_free_chan_resources() is completely unused and gcc quite rightfully warns about it: drivers/dma/ioatdma.c:247: warning: unused variable 'chanctrl' This patch removes the unused variable and silences the warning. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- ioatdma.c |1 - 1 file changed, 1 deletion(-) --- linux-2.6/drivers/dma/ioatdma.c~2007-09-16 23:24:20.0 +0200 +++ linux-2.6/drivers/dma/ioatdma.c 2007-09-16 23:24:20.0 +0200 @@ -244,7 +244,6 @@ static void ioat_dma_free_chan_resources struct ioat_dma_chan *ioat_chan = to_ioat_chan(chan); struct ioat_device *ioat_device = to_ioat_device(chan->device); struct ioat_desc_sw *desc, *_desc; - u16 chanctrl; int in_use_descs = 0; ioat_dma_memcpy_cleanup(ioat_chan); - 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: [00/41] Large Blocksize Support V7 (adds memmap support)
On (16/09/07 19:53), J?rn Engel didst pronounce: > On Sat, 15 September 2007 01:44:49 -0700, Andrew Morton wrote: > > On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote: > > > > > While I agree with your concern, those numbers are quite silly. The > > > chances of 99.8% of pages being free and the remaining 0.2% being > > > perfectly spread across all 2MB large_pages are lower than those of SHA1 > > > creating a collision. > > > > Actually it'd be pretty easy to craft an application which allocates seven > > pages for pagecache, then one for , then seven for pagecache, > > then > > one for , etc. > > > > I've had test apps which do that sort of thing accidentally. The result > > wasn't pretty. > > I bet! My (false) assumption was the same as Goswin's. If non-movable > pages are clearly seperated from movable ones and will evict movable > ones before polluting further mixed superpages, Nick's scenario would be > nearly infinitely impossible. > It would be plain impossible from a fragmentation point-of-view but you meet interesting situations when a GFP_NOFS allocation has no kernel blocks available to use. It can't reclaim, maybe it can move but not with current code (it should be able to with the Memory Compaction patches). > Assumption doesn't reflect current code. Enforcing this assumption > would cost extra overhead. The amount of effort to make Christoph's > approach work reliably seems substantial and I have no idea whether it > would be worth it. > Current code doesn't reflect your assumptions simply because the costs are so high. We'd need to be really sure it's worth it and if the answer is "yes", then we are looking at Andrea's approach (more likely) or I can check out evicting blocks of 16KB, 64KB or whatever the large block is. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - 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: [00/41] Large Blocksize Support V7 (adds memmap support)
On Sun, Sep 16, 2007 at 09:54:18PM +0100, Mel Gorman wrote: > The 16MB is the size of a hugepage, the size of interest as far as I am > concerned. Your idea makes sense for large block support, but much less > for huge pages because you are incurring a cost in the general case for > something that may not be used. Sorry for the misunderstanding, I totally agree! > There is nothing to say that both can't be done. Raise the size of > order-0 for large block support and continue trying to group the block > to make hugepage allocations likely succeed during the lifetime of the > system. Sure, I completely agree. > At the risk of repeating, your approach will be adding a new and > significant dimension to the internal fragmentation problem where a > kernel allocation may fail because the larger order-0 pages are all > being pinned by userspace pages. This is exactly correct, some memory will be wasted. It'll reach 0 free memory more quickly depending on which kind of applications are being run. > It improves the probabilty of hugepage allocations working because the > blocks with slab pages can be targetted and cleared if necessary. Agreed. > That suggestion was aimed at the large block support more than > hugepages. It helps large blocks because we'll be allocating and freeing > as more or less the same size. It certainly is easier to set > slub_min_order to the same size as what is needed for large blocks in > the system than introducing the necessary mechanics to allocate > pagetable pages and userspace pages from slab. Allocating userpages from slab in 4k chunks with a 64k PAGE_SIZE is really complex indeed. I'm not planning for that in the short term but it remains a possibility to make the kernel more generic. Perhaps it could worth it... Allocating ptes from slab is fairly simple but I think it would be better to allocate ptes in PAGE_SIZE (64k) chunks and preallocate the nearby ptes in the per-task local pagetable tree, to reduce the number of locks taken and not to enter the slab at all for that. Infact we could allocate the 4 levels (or anyway more than one level) in one single alloc_pages(0) and track the leftovers in the mm (or similar). > I'm not sure what you are getting at here. I think it would make more > sense if you said "when you read /proc/buddyinfo, you know the order-0 > pages are really free for use with large blocks" with your approach. I'm unsure who reads /proc/buddyinfo (that can change a lot and that is not very significant information if the vm can defrag well inside the reclaim code), but it's not much different and it's more about knowing the real meaning of /proc/meminfo, freeable (unmapped) cache, anon ram, and free memory. The idea is that to succeed an mmap over a large xfs file with mlockall being invoked, those largepages must become available or it'll be oom despite there are still 512M free... I'm quite sure admins will gets confused if they get oom killer invoked with lots of ram still free. The overcommit feature will also break, just to make an example (so much for overcommit 2 guaranteeing -ENOMEM retvals instead of oom killage ;). > All this aside, there is nothing mutually exclusive with what you are > proposing > and what grouping pages by mobility does. Your stuff can exist even if > grouping > pages by mobility is in place. In fact, it'll help us by giving an important > comparison point as grouping pages by mobility can be trivially disabled with > a one-liner for the purposes of testing. If your approach is brought to being > a general solution that also helps hugepage allocation, then we can revisit > grouping pages by mobility by comparing kernels with it enabled and without. Yes, I totally agree. It sounds worthwhile to have a good defrag logic in the VM. Even allocating the kernel stack in today kernels should be able to benefit from your work. It's just comparing a fork() failure (something that will happen with ulimit -n too and that apps must be able to deal with) with an I/O failure that worries me a bit. I'm quite sure a db failing I/O will not recover too nicely. If fork fails that's most certainly ok... at worst a new client won't be able to connect and he can retry later. Plus order 1 isn't really a big deal, you know the probability to succeeds decreases exponentially with the order. - 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] cifs: Fix a small memory leak in directory creation code.
There is a small memory leak in fs/cifs/inode.c::cifs_mkdir().
Storage for 'pInfo' is allocated with kzalloc(), but if the call
to CIFSPOSIXCreate(...) happens to return 0 and pInfo->Type == -1,
then we'll jump to the 'mkdir_get_info' label without freeing the
storage allocated for 'pInfo'.
This patch adds a kfree() call to free the storage just before
jumping to the label, thus getting rid of the leak.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
inode.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6/fs/cifs/inode.c~ 2007-09-16 23:01:52.0 +0200
+++ linux-2.6/fs/cifs/inode.c 2007-09-16 23:01:52.0 +0200
@@ -929,8 +929,10 @@ int cifs_mkdir(struct inode *inode, stru
d_drop(direntry);
} else {
int obj_type;
- if (pInfo->Type == -1) /* no return info - go query */
+ if (pInfo->Type == -1) { /* no return info - go query */
+ kfree(pInfo);
goto mkdir_get_info;
+ }
/*BB check (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SET_UID ) to see if need
to set uid/gid */
inc_nlink(inode);
-
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: [00/41] Large Blocksize Support V7 (adds memmap support)
On (15/09/07 02:31), Goswin von Brederlow didst pronounce: > Mel Gorman <[EMAIL PROTECTED]> writes: > > > On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote: > >> Nick Piggin <[EMAIL PROTECTED]> writes: > >> > >> > In my attack, I cause the kernel to allocate lots of unmovable > >> > allocations > >> > and deplete movable groups. I theoretically then only need to keep a > >> > small number (1/2^N) of these allocations around in order to DoS a > >> > page allocation of order N. > >> > >> I'm assuming that when an unmovable allocation hijacks a movable group > >> any further unmovable alloc will evict movable objects out of that > >> group before hijacking another one. right? > >> > > > > No eviction takes place. If an unmovable allocation gets placed in a > > movable group, then steps are taken to ensure that future unmovable > > allocations will take place in the same range (these decisions take > > place in __rmqueue_fallback()). When choosing a movable block to > > pollute, it will also choose the lowest possible block in PFN terms to > > steal so that fragmentation pollution will be as confined as possible. > > Evicting the unmovable pages would be one of those expensive steps that > > have been avoided to date. > > But then you can have all blocks filled with movable data, free 4K in > one group, allocate 4K unmovable to take over the group, free 4k in > the next group, take that group and so on. You can end with 4k > unmovable in every 64k easily by accident. > As the mixing takes place at the lowest possible block, it's exceptionally difficult to trigger this. Possible, but exceptionally difficult. As I have stated repeatedly, the guarantees can be made but potential hugepage allocation did not justify it. Large blocks might. > There should be a lot of preassure for movable objects to vacate a > mixed group or you do get fragmentation catastrophs. We (Andy Whitcroft and I) did implement something like that. It hooked into kswapd to clean mixed blocks. If the caller could do the cleaning, it did the work instead of kswapd. > Looking at my > little test program evicting movable objects from a mixed group should > not be that expensive as it doesn't happen often. It happens regularly if the size of the block you need to keep clean is lower than min_free_kbytes. In the case of hugepages, that was always the case. > The cost of it > should be freeing some pages (or finding free ones in a movable group) > and then memcpy. Freeing pages is not cheap. Copying pages is cheaper but not cheap. > With my simplified simulation it never happens so I > expect it to only happen when the work set changes. > > >> > And it doesn't even have to be a DoS. The natural fragmentation > >> > that occurs today in a kernel today has the possibility to slowly push > >> > out > >> > the movable groups and give you the same situation. > >> > >> How would you cause that? Say you do want to purposefully place one > >> unmovable 4k page into every 64k compund page. So you allocate > >> 4K. First 64k page locked. But now, to get 4K into the second 64K page > >> you have to first use up all the rest of the first 64k page. Meaning > >> one 4k chunk, one 8k chunk, one 16k cunk, one 32k chunk. Only then > >> will a new 64k chunk be broken and become locked. > > > > It would be easier early in the boot to mmap a large area and fault it > > in in virtual address order then mlock every a page every 64K. Early in > > the systems lifetime, there will be a rough correlation between physical > > and virtual memory. > > > > Without mlock(), the most successful attack will like mmap() a 60K > > region and fault it in as an attempt to get pagetable pages placed in > > every 64K region. This strategy would not work with grouping pages by > > mobility though as it would group the pagetable pages together. > > But even with mlock the virtual pages should still be movable. They are. The Memory Compaction patches were able to do the job. > So if > you evict movable objects from mixed group when needed all the > pagetable pages would end up in the same mixed group slowly taking it > over completly. No fragmentation at all. See how essential that > feature is. :) > To move pages, there must be enough blocks free. That is where min_free_kbytes had to come in. If you cared only about keeping 64KB chunks free, it makes sense but it didn't in the context of hugepages. > > Targetted attacks on grouping pages by mobility are not very easy and > > not that interesting either. As Nick suggests, the natural fragmentation > > over long periods of time is what is interesting. > > > >> So to get the last 64k chunk used all previous 32k chunks need to be > >> blocked and you need to allocate 32k (or less if more is blocked). For > >> all previous 32k chunks to be blocked every second 16k needs to be > >> blocked. To block the last of those 16k chunks all previous 8k chunks > >> need to be blocked and you need to allocate 8k. For al
Re: Wasting our Freedom
On Sun, Sep 16, 2007 at 10:39:26PM +0200, Hannah Schroeter wrote:
> Hi!
>
> On Sun, Sep 16, 2007 at 09:59:09PM +0200, Adrian Bunk wrote:
> >On Sun, Sep 16, 2007 at 11:48:47AM -0700, Can E. Acar wrote:
> >>...
> >> First, these developers got questionable advice from senior Linux kernel
> >> developers, and SLFC (which is closely related to FSF) in the process.
>
> >The most questionable legal advice in this thread was by Theo de Raadt
> >who claimed choosing one licence for _dual-licenced_ code was illegal...
>
> JFTR, I do *not* think that that assessment was questionable. Unless the
> dual-licensing *explicitly* allows relicensing, relicensing is forbidden
> by copyright law. The dual-licensing allows relicensing only if that's
> *explicitly* stated, either in the statement offering the alternative, or
> in one of the licenses.
Dual licenced code by definition explicitely states that you can choose
the licence - otherwise it wouldn't be called dual-licenced.
> Neither GPL nor BSD/ISC allow relicensing in their well-known wordings.
Noone said otherwise.
> If you think that's questionable, you should at least provide arguments
> (and be ready to have your interpretation of the law and the licenses
> tested before court).
The licence in question was:
<-- snip -->
/*-
* Copyright (c) 2002-2004 Sam Leffler, Errno Consulting
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer,
*without modification.
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
*similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
*redistribution must be conditioned upon including a substantially
*similar Disclaimer requirement for further binary redistribution.
* 3. Neither the names of the above-listed copyright holders nor the names
*of any contributors may be used to endorse or promote products derived
*from this software without specific prior written permission.
*
* Alternatively, this software may be distributed under the terms of the
* GNU General Public License ("GPL") version 2 as published by the Free
* Software Foundation.
*
* NO WARRANTY
* ...
<-- snip -->
Theo claimed it would "break the law" [1] to choose the GPL for
_this_ code. [2]
> >[...]
>
> >Regarding ethics - if you use the BSD licence for your code you state in
> >the licence text that it's OK that I take your code and never give
> >anything back.
>
> But the BSDl does not allow you to relicense the original code, even
> while it allows you to license copyrightable additions/modifications
> under different terms with few restrictions.
>
> However, you say "regarding ethics" and just go back to the legal level.
> Is it really ethical, if you consider both Linux and OpenBSD part of one
> OSS "community", to share things only in one direction? To take the
> reverse engineered HAL but to not allow OpenBSD to take some
> modifications back?
Is it really ethical to use a licence that does not require to give
back, but then demand that something has to be given back?
Why don't you use a licence that expresses your intentions in a legally
binding way?
> >[...]
>
> >Some people have the funny position of opposing the GPL which enforces
> >that you have to give back, but whining that people took their BSD
> >licenced code and don't give back.
>
> A difference is, GPL requires it under every circumstance. BSD does not,
> indeed. But how should one expect it from *OSS* people that even *they*
> don't give back? Do you really want to put yourself on the same level as
> closed-source companies?
You could also see it from a different perspective:
If you like that the GPL enforces that everyone has to give back, do you
also want to see your code BSD licenced without this protection?
But the truth is a bit less harsh:
In reality most Linux kernel developers might not mind to give back -
and e.g. much of the ACPI code is BSD/GPL dual-licenced, and there
doesn't seem to be any problem with this.
But Theo's wrong accusations regarding dual licenced code might not be
the best way for starting a fruitful collaboration...
> >[...]
>
> Kind regards,
>
> Hannah.
cu
Adrian
[1] http://lkml.org/lkml/2007/9/1/102
[2] The fact that Alan didn't notice that part of Jiri's patch touched
non-dual-licenced code is the mistake I already mentioned - but
this mistake is not what Theo is ranting about.
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe
Re: Wasting our Freedom
On Sun, Sep 16, 2007 at 10:39:26PM +0200, Hannah Schroeter wrote: > >The most questionable legal advice in this thread was by Theo de Raadt > >who claimed choosing one licence for _dual-licenced_ code was illegal... > > JFTR, I do *not* think that that assessment was questionable. Unless the > dual-licensing *explicitly* allows relicensing, relicensing is forbidden > by copyright law. The dual-licensing allows relicensing only if that's > *explicitly* stated, either in the statement offering the alternative, or > in one of the licenses. > > Neither GPL nor BSD/ISC allow relicensing in their well-known wordings. > > If you think that's questionable, you should at least provide arguments > (and be ready to have your interpretation of the law and the licenses > tested before court). Hannah, What is going on whenever someone changes a code is that they make a "derivative work". Whether or not you can even make a derivative work, and under what terms the derivitive work can be licensed, is strictly up to the license of the original. For example, the BSD license says: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met Note the "with or without modification". This is what allows people to change BSD licensed code and redistribute said changes. The conditions specified by the BSD license do not mention anything about licening terms --- just that if you meet these three conditions, you are allowed to redistribute them. So for example, this is what allows Network Appliances to take BSD code, change it, and add a restrictive, proprietary copyright. So for code which is single-licensed under a BSD license, someone can create a new derived work, and redistribute it under a more restrictive license --- either one as restrictive as NetApp's (where no one is allowed to get binary unless they are a NetApp customer, or source only after signing an NDA), or a GPL license. It is not a relicencing, per se, since the original version of the file is still available under the original copyright; it is only the derived work which is under the more restrictive copyright. Now, the original copyright can say that you aren't allowed to do this; for example, the GPL says that you are not allowed to add any restrictions on the copyright license of any derived works of GPL'ed code. This is why some BSD partisans claim that their license is "more free"; the BSD license allows people to add more restrictive copyright license terms on derived works. OK, what about dual licensed works? The specific wording of the dual licensing is that you can use *either* license. That means, you can treat code as if only using the BSD license applied, or only if the GPL license applied. That is, the end-user can redistribute if either the conditions required by the BSD license *or* the GPL license applied. But we've already shown that the BSD license allows the creation of a derived work with a more restrictive license --- such as the GPL. But don't take my word for it; the Software Freedom Law Center has issued advice, pro bono, written by lawyers about how this can be done. If you want, feel free get your own lawyers and ask them to provide formal legal advice. > A difference is, GPL requires it under every circumstance. BSD does not, > indeed. But how should one expect it from *OSS* people that even *they* > don't give back? Do you really want to put yourself on the same level as > closed-source companies? The problem with your argument is that BSD folks have claimed that the BSD license is morally superior --- "more free than the GPL" --- because you don't have to "give back" (or more formally, create a derivitive work with a copyright license more restrictive than the BSD). If that is true, it is the absolute height of hypocrisy to suddenly start complaining when code is restricted via an another open source license such as the GPL, but not complain when NetApp uses BSD code to make million and millions of dollars without giving anything of substantial value back. At least in the case of GPL'ed code you still can look at the changes and decide how and whether you to reimplement them. Why don't you go and try asking NetApp for sources to WAFL, and claim that they have "moral" duty to give the code back, and see how quickly you get laughed out of the office? - Ted - 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: Wasting our Freedom
On Sunday 16 September 2007 16:39:26 Hannah Schroeter wrote: > Hi! > > On Sun, Sep 16, 2007 at 09:59:09PM +0200, Adrian Bunk wrote: > >On Sun, Sep 16, 2007 at 11:48:47AM -0700, Can E. Acar wrote: > >>... > >> First, these developers got questionable advice from senior Linux kernel > >> developers, and SLFC (which is closely related to FSF) in the process. > > > >The most questionable legal advice in this thread was by Theo de Raadt > >who claimed choosing one licence for _dual-licenced_ code was illegal... > > JFTR, I do *not* think that that assessment was questionable. Unless the > dual-licensing *explicitly* allows relicensing, relicensing is forbidden > by copyright law. The dual-licensing allows relicensing only if that's > *explicitly* stated, either in the statement offering the alternative, or > in one of the licenses. That advice wasn't regarding relicensing. Dual-licensed code allows distribution and use under either license. If I get BSD/GPL code, I can follow the GPL exclusively and I don't have to follow the BSD license at all. And the alternative is also true. (ie: follow the BSD license exclusively and ignore the GPL) It's not "relicensing" - it's following *WHICH* of the offered terms are more agreeable. I'll just snip the rest, since you seem confused. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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 v3] menuconfig: distinguish between selected-by-another options and comments
On Sunday 16 of September 2007 21:36:54 Roman Zippel wrote:
> On Sun, 16 Sep 2007, Matej Laitl wrote:
> > The v2 was maybe more intuitive, but had at least one flaw, where it claimed
> > the option was selected by another, while it was in fact only made
> > unchangeable by 'bool "Enable block layer" if EMBEDDED', defaulting to y.
>
> The point is that I'm getting more concerned about overloading the
> interface with nontrivial information.
> Another direction to consider would be to add this information to the help
> text, e.g. choose one syntax for nonchangable symbols and then the user
> can press help to find more detailed information.
If I understand clearly, something similar is already in v3 (hunk took from
in-progress v4):
@@ -359,6 +369,11 @@ static void get_symbol_str(struct gstr *r, struct symbol
*sym)
str_printf(r, "Symbol: %s [=%s]\n", sym->name,
sym_get_string_value(sym));
+ if (sym_get_rev_dep(sym) != no)
+ str_printf(r, "Enforced value: %s (see Selected by:)\n",
+ sym_get_rev_dep(sym) == mod ? "[m] or [y]" :
"[y]");
+ if (sym_get_visibility(sym) == no)
+ str_append(r, _("None of the prompts active, default value
assigned\n"));
for_all_prompts(sym, prop)
get_prompt_str(r, prop);
> > The function names are maybe suboptimal, I agree.
>
> The variable name is already correct, it's the visibility value of a
> symbol not its maximum. In the case of the "if EMBEDDED" then individual
> menu entries can still be visible, if any child entry is visible (see
> menu_is_visible()).
Changed function names to sym_get_rev_dep() and sym_get_visibility().
Shouldn't I move them from symbol.c and lkc_proto.h into lkc.h? They would
fit into the section with static inline one-liners.
Bye,
Matej.
-
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: [00/41] Large Blocksize Support V7 (adds memmap support)
On (16/09/07 17:08), Andrea Arcangeli didst pronounce: > On Sun, Sep 16, 2007 at 03:54:56PM +0200, Goswin von Brederlow wrote: > > Andrea Arcangeli <[EMAIL PROTECTED]> writes: > > > > > On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote: > > >> - Userspace allocates a lot of memory in those slabs. > > > > > > If with slabs you mean slab/slub, I can't follow, there has never been > > > a single byte of userland memory allocated there since ever the slab > > > existed in linux. > > > > This and other comments in your reply show me that you completly > > misunderstood what I was talking about. > > > > Look at > > http://www.skynet.ie/~mel/anti-frag/2007-02-28/page_type_distribution.jpg > > What does the large square represent here? A "largepage"? If yes, > which order? There seem to be quite some pixels in each square... > hmm, it was a long time ago. This one looks like 4MB large pages so order-10 > > The red dots (pinned) are dentries, page tables, kernel stacks, > > whatever kernel stuff, right? > > > > The green dots (movable) are mostly userspace pages being mapped > > there, right? > > If the largepage is the square, there can't be red pixels mixed with > green pixels with the config-page-shift design, this is the whole > difference... Yes. I can enforce a similar situation but didn't because the evacuation costs could not be justified for hugepage allocations. Patches to do such a thing were prototyped a long time ago and abandoned based on cost. For large blocks, there may be a justification. > zooming in I see red pixels all over the squares mized with green > pixels in the same square. This is exactly what happens with the > variable order page cache and that's why it provides zero guarantees > in terms of how much ram is really "free" (free as in "available"). > This picture is not grouping pages by mobility so that is hardly a suprise. This picture is not running grouping pages by mobility. This is what the normal kernel looks like. Look at the videos in http://www.skynet.ie/~mel/anti-frag/2007-02-28 and see how list-based compares to vanilla. These are from February when there was less control over mixing blocks than there is today. In the current version mixing occurs in the lower blocks as much as possible not the upper ones. So there are a number of mixed blocks but the number is kept to a minimum. The number of mixed blocks could have been enforced as 0, but I felt it was better in the general case to fragment rather than regress performance. That may be different for large blocks where you will want to take the enforcement steps. > > What I was refering too is that because movable objects (green dots) > > aren't moved out of a mixed group (the boxes) when some unmovable > > object needs space all the groups become mixed over time. That means > > the unmovable objects are spread out over all the ram and the buddy > > system can't recombine regions when unmovable objects free them. There > > will nearly always be some movable objects in the other buddy. The > > system of having unmovable and movable groups breaks down and becomes > > useless. > > If I understood correctly, here you agree that mixing movable and > unmovable objects in the same largepage is a bad thing, and that's > incidentally what config-page-shift prevents. It avoids it instead of > undoing the mixture later with defrag when it's far too late for > anything but updatedb. > We don't take defrag steps at the moment at all. There are memory compaction patches but I'm not pushing them until we can prove they are necessary. > > I'm assuming here that we want the possibility of larger order pages > > for unmovable objects (large continiuos regions for DMA for example) > > than the smallest order user space gets (or any movable object). If > > mmap() still works on 4k page bounaries then those will fragment all > > regions into 4k chunks in the worst case. > > With config-page-shift mmap works on 4k chunks but it's always backed > by 64k or any other largesize that you choosed at compile time. And if > the virtual alignment of mmap matches the physical alignment of the > physical largepage and is >= PAGE_SIZE (software PAGE_SIZE I mean) we > could use the 62nd bit of the pte to use a 64k tlb (if future cpus > will allow that). Nick also suggested to still set all ptes equal to > make life easier for the tlb miss microcode. > As I said elsewhere, you can try this easily on top of grouping pages by mobility. They are not mutually exclusive and you'll have a comparison point. > > Obviously if userspace has a minimum order of 64k chunks then it will > > never break any region smaller than 64k chunks and will never cause a > > fragmentation catastroph. I know that is verry roughly your aproach > > (make order 0 bigger), and I like it, but it has some limits as to how > > Yep, exactly this is what happens, it avoids that trouble. But as far > as fragmentation guarantees goes, it's really about k
Re: ACPI video mode patch review
Hi! > > Many thanks for taking care of this! > > > > We already have a patch in -mm, s2ram-kill-old-debugging-junk.patch from > > Pavel > > (http://marc.info/?l=linux-mm-commits&m=118737955611331&w=1), that removes > > the > > #ifdefed blocks and it clashes with your first patch a bit. > > > > FYI, I have rebased your first patch on top of the Pavel's patch: > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc6/patches/39-acpi-video-mode-fix.patch > > > > Thanks Rafael, > > However, I need to send something upstream to Linus for this kernel > cycle, so I don't want to base it on an -mm patch. There are two > alternatives, obviously: 1. send my patch in now based on the "change as > little as necessary to fix the immediate problem" and then rebase > Pavel's patch on top of mine, or 2. for me to send both Pavel's patch > and the rebased patch upstream. > > Personally, I would prefer to avoid strategy 2 at this late stage in the > 2.6.23-rc series. Agreed we should have the fix in 2.6.23... Actually doing 2 does not seem like a big problem, my patch is pretty straight cleanup (and may even fix some machines, as we avoid touching video ram)... But resolving conflict is not hard, either; I know, I did it :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [00/41] Large Blocksize Support V7 (adds memmap support)
On (16/09/07 20:50), Andrea Arcangeli didst pronounce: > On Sun, Sep 16, 2007 at 07:15:04PM +0100, Mel Gorman wrote: > > Except now as I've repeatadly pointed out, you have internal fragmentation > > problems. If we went with the SLAB, we would need 16MB slabs on PowerPC for > > example to get the same sort of results and a lot of copying and moving when > > Well not sure about the 16MB number, since I'm unsure what the size of > the ram was. The 16MB is the size of a hugepage, the size of interest as far as I am concerned. Your idea makes sense for large block support, but much less for huge pages because you are incurring a cost in the general case for something that may not be used. There is nothing to say that both can't be done. Raise the size of order-0 for large block support and continue trying to group the block to make hugepage allocations likely succeed during the lifetime of the system. > But clearly I agree there are fragmentation issues in the > slab too, there have always been, except they're much less severe, and > the slab is meant to deal with that regardless of the PAGE_SIZE. That > is not a new problem, you are introducing a new problem instead. > At the risk of repeating, your approach will be adding a new and significant dimension to the internal fragmentation problem where a kernel allocation may fail because the larger order-0 pages are all being pinned by userspace pages. > We can do a lot better than slab currently does without requiring any > defrag move-or-shrink at all. > > slab is trying to defrag memory for small objects at nearly zero cost, > by not giving pages away randomly. I thought you agreed that solving > the slab fragmentation was going to provide better guarantees when in It improves the probabilty of hugepage allocations working because the blocks with slab pages can be targetted and cleared if necessary. > another email you suggested that you could start allocating order > 0 > pages in the slab to reduce the fragmentation (to achieve most of the > guarantee provided by config-page-shift, but while still keeping the > order 0 at 4k for whatever reason I can't see). > That suggestion was aimed at the large block support more than hugepages. It helps large blocks because we'll be allocating and freeing as more or less the same size. It certainly is easier to set slub_min_order to the same size as what is needed for large blocks in the system than introducing the necessary mechanics to allocate pagetable pages and userspace pages from slab. > > a suitable slab page was not available. > > You ignore one other bit, when "/usr/bin/free" says 1G is free, with > config-page-shift it's free no matter what, same goes for not mlocked > cache. With variable order page cache, /usr/bin/free becomes mostly a > lie as long as there's no 4k fallback (like fsblock). > I'm not sure what you are getting at here. I think it would make more sense if you said "when you read /proc/buddyinfo, you know the order-0 pages are really free for use with large blocks" with your approach. > And most important you're only tackling on the pagecache and I/O > performance with the inefficient I/O devices, the whole kernel has no > cahnce to get a speedup, infact you're making the fast paths slower, > just the opposite of config-page-shift and original Hugh's large > PAGE_SIZE ;). > As the kernel pages are all getting grouped together, there are fewer TLB entries needed to address the kernels working set so there is a general improvement although how much is workload All this aside, there is nothing mutually exclusive with what you are proposing and what grouping pages by mobility does. Your stuff can exist even if grouping pages by mobility is in place. In fact, it'll help us by giving an important comparison point as grouping pages by mobility can be trivially disabled with a one-liner for the purposes of testing. If your approach is brought to being a general solution that also helps hugepage allocation, then we can revisit grouping pages by mobility by comparing kernels with it enabled and without. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - 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 video mode patch review
Rafael J. Wysocki wrote: > On Thursday, 13 September 2007 23:37, H. Peter Anvin wrote: >> Pavel, want to look at the patch before sending it to Linus? > > Many thanks for taking care of this! > > We already have a patch in -mm, s2ram-kill-old-debugging-junk.patch from Pavel > (http://marc.info/?l=linux-mm-commits&m=118737955611331&w=1), that removes the > #ifdefed blocks and it clashes with your first patch a bit. > > FYI, I have rebased your first patch on top of the Pavel's patch: > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc6/patches/39-acpi-video-mode-fix.patch > Thanks Rafael, However, I need to send something upstream to Linus for this kernel cycle, so I don't want to base it on an -mm patch. There are two alternatives, obviously: 1. send my patch in now based on the "change as little as necessary to fix the immediate problem" and then rebase Pavel's patch on top of mine, or 2. for me to send both Pavel's patch and the rebased patch upstream. Personally, I would prefer to avoid strategy 2 at this late stage in the 2.6.23-rc series. Please let me know what you think. -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: x86_64: vsyscall vs vdso
On 9/16/07, Francis Moreau <[EMAIL PROTECTED]> wrote: > I'm a bit puzzled because vdso doesn't seem to be used on my fedora 7: > I just compiled a trivial program which just call gettimeofday() and > ld.so resolves this call with vsyscall's gettimeofday. > > Now I'm wondering when vdso is used, could anybody give me a clue ? F7 was released before the vdso for x86_64 was upstream so you should not expect anything else. F8 will use the available vdso. This doesn't just happen magically, changes to libc are needed. > Another question: is vdso going to replace vsyscall at all ? If so how > are statically programs going to be handled ? Unfortunately the vsyscalls cannot ever go completely away. Statically linked apps, the bane of progress, will need them. There are also people updating kernels but not the user userland code. What we will have to do in future is to make vsyscalls configurable. Both a compile time option and a runtime option (perhaps also under control of SELinux) are likely needed. - 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: Wasting our Freedom
Hi! On Sun, Sep 16, 2007 at 09:59:09PM +0200, Adrian Bunk wrote: >On Sun, Sep 16, 2007 at 11:48:47AM -0700, Can E. Acar wrote: >>... >> First, these developers got questionable advice from senior Linux kernel >> developers, and SLFC (which is closely related to FSF) in the process. >The most questionable legal advice in this thread was by Theo de Raadt >who claimed choosing one licence for _dual-licenced_ code was illegal... JFTR, I do *not* think that that assessment was questionable. Unless the dual-licensing *explicitly* allows relicensing, relicensing is forbidden by copyright law. The dual-licensing allows relicensing only if that's *explicitly* stated, either in the statement offering the alternative, or in one of the licenses. Neither GPL nor BSD/ISC allow relicensing in their well-known wordings. If you think that's questionable, you should at least provide arguments (and be ready to have your interpretation of the law and the licenses tested before court). >[...] >Regarding ethics - if you use the BSD licence for your code you state in >the licence text that it's OK that I take your code and never give >anything back. But the BSDl does not allow you to relicense the original code, even while it allows you to license copyrightable additions/modifications under different terms with few restrictions. However, you say "regarding ethics" and just go back to the legal level. Is it really ethical, if you consider both Linux and OpenBSD part of one OSS "community", to share things only in one direction? To take the reverse engineered HAL but to not allow OpenBSD to take some modifications back? >[...] >Some people have the funny position of opposing the GPL which enforces >that you have to give back, but whining that people took their BSD >licenced code and don't give back. A difference is, GPL requires it under every circumstance. BSD does not, indeed. But how should one expect it from *OSS* people that even *they* don't give back? Do you really want to put yourself on the same level as closed-source companies? >[...] Kind regards, Hannah. - 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: kbuild update
On Sun, Sep 16, 2007 at 12:23:43PM -0700, Andrew Morton wrote: > On Sun, 16 Sep 2007 08:58:03 -0400 (EDT) "Robert P. J. Day" <[EMAIL > PROTECTED]> wrote: > > > On Sun, 16 Sep 2007, Sam Ravnborg wrote: > > > > > A summary of what is planned to be submitted in next merge window for > > > kbuild. > > > The shortlog below have additional details but the headlines are: > > ... > > > o add script to find unused kconfig symbols (try it!) > > > > based on my experiences with this, unless you filter carefully, you're > > going to end up with a *whack* of false positives given the number of > > developers who elect to name their local macros starting with a prefix > > of "CONFIG_". good luck dealing with *that*. :-) > > box:/usr/src/linux-2.6.23-rc6> grep -r '^[ ]*#[]*define[ > ]*CONFIG_' . | wc -l > 415 > > bah. They're all bugs - The CONFIG_foo namespace is (should be) reserved in > kernel coding. I get (after a bit more filtering 349 hits of which 182 are outside drivers/ Of the 182 the 25 of them are in arch specific code. I se no good reasons to address this unless we touch code in that area anyway. But avoiding new entries are good. Sam - 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: Wasting our Freedom
On Sun, Sep 16, 2007 at 02:17:53AM -0700, J.C. Roberts wrote: > Look at what you are saying from a different perspective. Let's say > someone took the linux kernel source from the official repository, > removed the GPL license and dedicated the work to public domain or put > it under any other license, and for kicks back-dated the files so they > are older than the originals. Then they took this illegal license > removal copy of your code and put it in a public repository somewhere. Ok, suppose someone did (precisely) this. Then the person to be upset with would be the people who did this, not the people behind the official repository. Some folks seem to be unfortuntaely blaming the people who run the official repository. Look, it's perhaps a little understandable that people in the *BSD world might not understand that the Linux development community is huge, and not understand that the people who work on madwifi.org, the core kernel community, and the FSF, are distinct, and while they might interact with each other, one part of the community can't dictate what another part of the community does. You wouldn't want us to conflate all of the security faults of say, NetBSD with OpenBSD, just because it came from a historically similar code base and "besides all you *BSD folks are all the same --- if you don't want a bad reputation, why don't you police yourselves"? Would you not say this is unreasonable? If so, would you kindly not do the same thing to the Linux community? Secondly, it looks like people are getting worked up about two different things, and in some cases it looks like the two things are getting conflated. The first thing is a screw-up about attribution and removal of the BSD license text, and that is one where the SFLC has already issued advice that this is bad ju-ju, and that the BSD license text must remain intact. The second case which seems to get people upset is that there are people who are taking BSD code, and/or GPL/BSD dual licensed code, and adding code additions/improvements/changes under a GPL-only license. This is very clearly legal, just as it is clearly legal for NetApp to take the entire BSD code base, add proprietary changes to run on their hardware and to add a propietary, patent-encrusted WAFL filesystem, and create a codebase which is no longer available to the BSD development community. The first case was clearly a legal foul, whereas the second case is legally O.K (whether the GPL or NetApp propietary license is involved). However, people are conflating these two cases, and using words like "theft" and "copyright malpractice", without being clear which case they are talking about. If we grant that the first is bad, and is being rectified before it gets merged into the mainline kernel, can we please drop this? If you are truely offended that working pre-merge copies of the files with the incorrect copyright statements still exist on the web, feel free to send requests to madwifi.org, the Wayback Archive, and everywhere else to stamp them out --- but can you please leave the Linux Kernel Mailing List out of it, please? As far as the second case is concerned, while it is clearly _legally_ OK, there is a question whether it is _morally_ a good idea. And this is where a number of poeple in the Linux camp are likely to accuse the *BSD people who are making a huge amount of fuss of being hypocrites. After all, most BSD people talk about how they are *proud* that companies like NetApp can take the BSD code base, and make improvements, and it's OK that those improvements never make it back to the BSD code base. In fact, these same *BSD folks talk about how this makes the BSD license "more free" than the GPL. Yet, when some people want to take BSD code (and let's assume that proper attributions and copyright statements are retained, just as I'll assume that NetApp also preserved the same copyright statements and attributions), and make improvements that are under the GPL, at least some *BSD developers are rising up and claiming "theft"! Um, hello? Why is it OK for NetApp to do it, and not for some Linux wireless developers to do precisely the same thing? Is it because the GPL license is open source? At least that way you can see the improvements (many of them would have been OS-specific anyway, since the BSD and Linux kernel infrastructures are fundamentally different), and then reimplement yourself in the case of NetApp, you don't even get to **see** the sources to the WAFL filesystem; they are, after all, under a proprietary copyright license. The final argument that could be made is the practical one; that regardless of whether or not a Linux wireless developer has any legal or moral right to do what NetApp developers have done years ago, that it would be better to cooperate. That's a judgement call, and I'll assume that the BSD wireless developers are different from the people who are screaming and trolling on the kernel mailing list --- si
Re: Wasting our Freedom
On Sunday 16 September 2007 14:48:47 Can E. Acar wrote: > On Sunday 16 September 2007 15:23:25 Daniel Hazelton wrote: > > On Sunday 16 September 2007 05:17:53 J.C. Roberts wrote: > >> On Sunday 16 September 2007, Jeff Garzik wrote: > >> > J.C. Roberts wrote: > >> > > http://marc.info/?l=linux-wireless&m=118857712529898&w=2 > >> > > >> > Link with outdated info. > >> > > >> > > http://madwifi.org/browser/branches/ath5k > >> > > >> > Link with outdated info. > >> > > >> > > I suggest actually taking the time to get the facts before making > >> > > completely baseless statements. When you make obviously erroneous > >> > > statements, it leaves everyone to believe you are either hopelessly > >> > > misinformed, or a habitual liar. -Which is it? > >> > > >> > Please take a moment to understand the Linux development process. > >> > > >> > A better place to look would be 'ath5k' branch of > >> > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.g > >> >it > >> > > >> > but nonethless, the fact remains that ath5k is STILL NOT UPSTREAM and > >> > HAS NEVER BEEN UPSTREAM, as can be verified from > >> > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > >> > (official linux repo; nothing is official until it hits here) > >> > > >> > Part of the reason why ath5k is not upstream is that developers are > >> > actively addressing these copyright concerns -- as can be clearly > >> > seen by the changes being made over time. > >> > > >> > So let's everybody calm down, ok? > >> > > >> > Regards, > >> > > >> > Jeff > >> > >> Jeff, > >> > >> Look at what you are saying from a different perspective. Let's say > >> someone took the linux kernel source from the official repository, > >> removed the GPL license and dedicated the work to public domain or put > >> it under any other license, and for kicks back-dated the files so they > >> are older than the originals. Then they took this illegal license > >> removal copy of your code and put it in a public repository somewhere. > >> > >> You'd be perfectly content with such a development because it had not > >> been officially brought "upstream" by the "offical" public domain or > >> whatever project? > > > > But that isn't the situation being discussed. You've sent this mail to > > the *LINUX* *KERNEL* ML, not the MadWifi ML. The patches in question were > > not accepted into the Linux Kernel, so this is *NOT* the place to send > > mail related to them. > > You are so cleanly isolating and cutting away of a group of developers. > I sincerely hope your fellow developers will not cut you off if you > make a similar mistake. I know mine wont. No, I'm saying "You are complaining about this in the wrong place and accusing the wrong people of the misdeed." > What you are saying is, a Copyright violation done by someone else is > Somebody Else's Problem (tm). There are a couple of issues with this point > of view: > > First, these developers got questionable advice from senior Linux kernel > developers, and SLFC (which is closely related to FSF) in the process. IIRC, the advice was "Yes, it is legal to choose to follow only one of multiple offered licenses on a project" - nothing else. They looked at the patches and said "Wait, you've changed the license on files that aren't under a dual license." Hence, no problems here - no questionable advice only. > > > *PLEASE* go do a Google search or check the MadWifi site for their > > discussion list/forum/whatever and complain there. > > This has been done. Really. They have been contacted privately > before the issue became public. Got no results. The issue is then made > public, > with the results you see now. This is no longer a MadWifi problem. Then file the lawsuit - if they have violated the license and ignored requests to fix the problem then there is sound legal grounds for it. > > > If the OpenBSD developers want to attack the Linux Kernel community over > > patches that were *NEVER* *ACCEPTED* by said community, it should be just > > as fair for the Linux Kernel community to complain about those > > (unspecified) times where OpenBSD replaced the GPL on code with the BSD > > license. > > It is fair. All license issues deserve utmost attention and respect by > all communities. If we let such issues to go unresolved, we face a > much greater danger to our work. Yes, but in this case you are complaining to people that have no control over the code in question. It's known that the patches are bad, and if people continue to use them, then it is their problem and the problem of the copyright holder. > > Is it too naive to hope that some leader/senior developer from the > Linux/FSF/GNU > whatever will take the clue stick and let the developers know what is > happening > is wrong. Being leaders in a community do have some responsibilities you > know. And it has happened - the Linux Kernel community has commented on the situation a *LOT* - to the extent that the patches in que
x86_64: vsyscall vs vdso
Hello, I'm a bit puzzled because vdso doesn't seem to be used on my fedora 7: I just compiled a trivial program which just call gettimeofday() and ld.so resolves this call with vsyscall's gettimeofday. Now I'm wondering when vdso is used, could anybody give me a clue ? Another question: is vdso going to replace vsyscall at all ? If so how are statically programs going to be handled ? Thanks, -- Francis - 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] Fujitsu application panel driver (rev3)
Hi Stephen, On Sunday 16 September 2007 15:55, Stephen Hemminger wrote: > On Fri, 14 Sep 2007 01:30:58 -0400 > Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > Hi Stephen, > > > > On Wednesday 12 September 2007 07:38, Stephen Hemminger wrote: > > > This driver supports the application buttons on some Fujitsu Lifebook > > > laptops. > > > It is based on the earlier apanel driver done by Jochen Eisenger, but > > > with many changes. The original driver used ioctl's and a separate > > > user space program; see http://apanel.sourceforge.net/tech.php > > > This version hooks into the input subsystem so that the normal > > > Gnome/KDE shortcuts work without any userspace changes. > > > > > > The Mail Led is handled via leds class device. > > > > > > > Thank you very much for convering the led to led subsystem. I tried > > implementing loadable keymap support in the driver, could you please > > try the patch below and if it still works for you then I will apply > > it to my tree. > > > > Sorry, you are raising the bar for new drivers, higher than existing code. > It is really bad (second system syndrome), if maintainers keep wanting > new code to to more than existing drivers. > > Please take driver AS IS. Go ahead and add loadable key map support, I think I did that. I just asked you to run another test to make sure I did not screw up. Please find the time to do that and the patch will be applied. Unfortunately I do not own the hardware in question to do such test myself. > but fix all the other drivers in the tree at the same time that use the > existing > interface. > I will, time permitting. The support for doing loadable keymaps for drivers with sparse scancodes (or their equivalent) was added not so long ago, that's why there are a few drivers that don't implement loadable keymaps. But still many others do. -- 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: [RFC][PATCH] 9p: add readahead support for loose mode
On Sat, 15 Sep 2007 03:41:26 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > eww, kmap. Large amounts of them, apparently. > > Be aware that kmap is a) slow and b) deadlockable. The latter happens when > multiple tasks want to take more than one kmap simultaneously: they all > wait for someone else to release one. Your code here seems especially > vulnerable to this. > > Nick had a kmap-speedup patchset a while back which addressed a) but I > don't know if it addressed the deadlock. But that patch seemed to die. That would've been me. What I did to address b) is to pre-allocate each kmap user a second kmap slot. Of course this isn't water-tight either. These patches are part of -rt, I could respin against mainline if there is interest. - 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: Rename asm-offsets tool or not? (Re: [patch 01/03] kbuild, asm-values: infrastructure)
On Sun, Sep 16, 2007 at 09:32:58PM +0200, Oleg Verych wrote: > On Sun, Sep 16, 2007 at 08:29:12PM +0200, Sam Ravnborg wrote: > > Hi Oleg. > > Hallo. Nice, you are bringing it back. I'll try to have LKML-like > output this time, not a makefile mess and stuff: > > [] > > I see no value in renaming from asm_offset to asm_value - please drop it. > > Introducing the generic asm-values.h should wait and when you do > > you should be preapred to update all architectures (ecasue otherwise it > > will not happen). > > All archs, are using same syntax. But. > > Interesting exception is MIPS, where tokens are organized and implemented > more nicely, that is where *asm-values* name coming from, actually. One > can see all that text, size, constant tokens in addition to just offsets. > > So, if name change isn't worth, then OK; filename compatibility check, as > one in `linux/Kbuild', is easy to hack as well to remove. > > But nice feature/tool with meaningful name and functionality is just > another thing. > > Opinions? Everyone and their cousin these days knows that asm-offset is constants generated from C and used in assembler. If we benefit from more values in the asm-offset file - let's do it. But there is no reason to change a name that has been used for this purpose for as long as I can remember. Sam - 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: Wasting our Freedom
Daniel Hazelton wrote: If the OpenBSD developers want to attack the Linux Kernel community over patches that were *NEVER* *ACCEPTED* by said community, it should be just as fair for the Linux Kernel community to complain about those (unspecified) times where OpenBSD replaced the GPL on code with the BSD license. And, as said before, the place to take these complaints is the MadWifi discussion area, since they are, apparently, the only people that accepted the patches in question. Although it's true the code is not yet upstream... Given that we want support for Atheros (whenever all this mess is sorted), I think it's quite fair to discuss these issues [in a calm, rational, paranoia-free manner] on LKML or [EMAIL PROTECTED] *WE*, the people on the Linux Kernel ML, *CANNOT* "fix the problem" with the *MADWIFI* code having accepted patches which violate Reyk's copyright. Given that we want it upstream, it is however relevant. We want to make sure we are aware of copyright problems, and we want to make sure any copyright problems are fixed. On a side note: "MadWifi" does not really describe the Linux ath5k driver, the driver at issue here. Some mistakes were made by Linux wireless developers, and those mistakes were corrected. Linux Kernel != FSF/GNU If it was then RMS would not be attacking Linus and Linux with faulty claims just because Linus has publicly stated that the GPLv2 is a better license than v3 Amen. 100% agreed. 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: [PATCH]PCI:disable resource decode in PCI BAR detection
On Thu, 2007-09-13 at 21:32 -0600, Robert Hancock wrote: > > If we do encounter other devices that choke on having the BAR > disabled > during probing then we can add additional quirk logic, but we haven't > run into anything like that yet. Well... if the device needs to be accessed to service an interrupt then you do have a problem. For example... the PIC :-) Problem is.. it's not practical nor really feasible generally to have IRQs off on all CPUs during PCI probing neither... Unless we define that the initial boot time probing is "special", and the first pass that actually probes devices (and doesn't muck around with the sysfs hierarchy etc...) can be run in a special context with all interrupt servicing disabled on the PIC, though that will require some arch support. 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: regression: fireware causes oops during system
On Sunday, 16 September 2007 21:58, Stefan Richter wrote: > Rafael J. Wysocki wrote: > >> Pavel Machek wrote: > >>> commit 831441862956fffa17b9801db37e6ea1650b0f69 > >>> tree b0334921341f8f1734bdd3243de76d676329d21c > >>> parent 787d2214c19bcc9b6ac48af0ce098277a801eded > >>> author Rafael J. Wysocki <[EMAIL PROTECTED]> Tue, 17 Jul 2007 04:03:35 > >>> -0700 > >>> committer Linus Torvalds <[EMAIL PROTECTED]> Tue, 17 > >>> Jul 2007 10:23:02 -0700 > >>> > >>> Freezer: make kernel threads nonfreezable by default > > > > Well, I don't think so. > > > > nodemgr_host_thread() calls set_freezable() as it should. > > This commit is certainly OK, as it should merely preserve status quo. > Also note that Pavel wrote in his initial post that the problem became > apparent way after -rc1. Full quote: > > | I noticed empty suspend stopped working around 2.6.23-rc4, and it is > | still present in 2.6.23-rc6. To reproduce > | > | swapoff -a > | echo disk > /sys/power/state > | echo disk > /sys/power/state > | > | Unsetting > | > | CONFIG_IEEE1394=y > | > | solves the problem. Yes. I thought that there might be a later change that exposed a bug in it. Hm. Pavel, can you do # echo test > /sys/power/disk # echo disk > /sys/power/state and see what happens? Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]PCI:disable resource decode in PCI BAR detection
On Thu, 2007-09-13 at 15:16 +0400, Ivan Kokshaysky wrote: > On Thu, Sep 13, 2007 at 02:53:13AM -0700, Greg KH wrote: > > On Thu, Sep 13, 2007 at 01:55:36AM -0600, Matthew Wilcox wrote: > > > Unfortunately if this patch does cause any machine to break, these will > > > be machines that worked fine up until this point, so that would be a > > > regression, which is worse. Life sucks. > > > > If, after a while, you think the change should go into the -stable tree, > > I have no objection. > > I think it shouldn't - this change will almost certainly cause a regression. > There is a lot of system devices besides the host bridges that shouldn't be > disabled during BAR probe, like interrupt controllers, power management > controllers and so on. > > We need a more sophisticated fix - I'm thinking of introducing "probe" field > in struct pci_dev which can be set by "early" quirk routines. Agreed. I have a similar problem on ppc where it's common to have things like the main PIC on a PCI device. Note that another problem is (or at least was, i haven't checked recently) the P2P bridge scanning code that, in a similar way, can block the path to all devices below it. I -do- have a case for example with Apple Xserve G4's where the main Apple IO ASIC, which is a PCI device containing the PIC, the power management controller, and various low level system control IOs is behind a pair of P2P bridges. One solution for us (PPC) is to enforce those devices and bridges to be described in the OF tree, and generalize a bit the code we have for some 64 bits machines, that synthetizes the pci_dev's from the OF nodes rather than probing. But that's not going to help other archs. In fact, that's a problem we also have with pci_assign_unassigned_resources() which will happily move things around that must not be moved, especially when sitting behind P2P bridges. So the root of the issue is much deeper than just a quirk here I believe. Cheers, 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: Wasting our Freedom
On Sun, Sep 16, 2007 at 11:48:47AM -0700, Can E. Acar wrote: >... > First, these developers got questionable advice from senior Linux kernel > developers, and SLFC (which is closely related to FSF) in the process. The most questionable legal advice in this thread was by Theo de Raadt who claimed choosing one licence for _dual-licenced_ code was illegal... This was the first email that was forwarded to linux-kernel, and it made it really hard to see at first that there was also an accidental copyright violation in Jiri's (never merged) patch. > There have been complete silence from the leaders of their own > community (Linux Kernel developers, FSF, ...) >... s/community/communities/ This seems to be a common thinko by some people: The Linux kernel developers and the FSF are two very distinct communities, and there are quite different views on some copyright issues. There is no "GPL community" covering both, there might be some kind of "open source community" - but this would as well include OpenBSD. > This case illustrates some important issues that should interest ALL > free software developers: > > 1) How tricky code sharing between different projects can be even when >intents and goals are pretty much alike. It should now be resolved how to incorporate BSD licenced code correctly into GPL'ed code, or is there any unresolved legal problem? > 2) MANY developers on BOTH sides have NO clue about the laws and ethics >associated with handling Copyrights and Licenses. I agree with you regarding the laws. Regarding ethics - if you use the BSD licence for your code you state in the licence text that it's OK that I take your code and never give anything back. Both Linux and Microsoft have used BSD licenced code according to this licence. Some people have the funny position of opposing the GPL which enforces that you have to give back, but whining that people took their BSD licenced code and don't give back. Everyone can choose the licence he likes for his own code, but if intentions and licence text don't match that's the fault of the person who licenced his code that way. > 3) The copyrights and licenses are the foundations of our work. >We put out great usually volunteer work, to create and improve. >The licenses specify the terms and conditions under which we allow >our work to be used. When we allow ANY license violation to occur, >it affects our own work, regardless of the license on it. >... Who allowed any licence violation? Let's look at the facts: - Each year, at about two thousand different people contribute patches that get incorporated into the Linux kernel. - One of them made the mistake of accidentally sending a patch that would have wrongly deleted the BSD header from BSD code. - Other developers didn't notice this mistake when looking at the patch. - This patch has never been merged. A mistake. No bad intentions. Shit happens. Resolved as soon as people were made aware of the mistake. > Can cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression: fireware causes oops during system
Rafael J. Wysocki wrote: >> Pavel Machek wrote: >>> commit 831441862956fffa17b9801db37e6ea1650b0f69 >>> tree b0334921341f8f1734bdd3243de76d676329d21c >>> parent 787d2214c19bcc9b6ac48af0ce098277a801eded >>> author Rafael J. Wysocki <[EMAIL PROTECTED]> Tue, 17 Jul 2007 04:03:35 -0700 >>> committer Linus Torvalds <[EMAIL PROTECTED]> Tue, 17 >>> Jul 2007 10:23:02 -0700 >>> >>> Freezer: make kernel threads nonfreezable by default > > Well, I don't think so. > > nodemgr_host_thread() calls set_freezable() as it should. This commit is certainly OK, as it should merely preserve status quo. Also note that Pavel wrote in his initial post that the problem became apparent way after -rc1. Full quote: | I noticed empty suspend stopped working around 2.6.23-rc4, and it is | still present in 2.6.23-rc6. To reproduce | | swapoff -a | echo disk > /sys/power/state | echo disk > /sys/power/state | | Unsetting | | CONFIG_IEEE1394=y | | solves the problem. -- Stefan Richter -=-=-=== =--= = http://arcgraph.de/sr/ - 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 video mode patch review
On Thursday, 13 September 2007 23:37, H. Peter Anvin wrote: > Pavel, want to look at the patch before sending it to Linus? Many thanks for taking care of this! We already have a patch in -mm, s2ram-kill-old-debugging-junk.patch from Pavel (http://marc.info/?l=linux-mm-commits&m=118737955611331&w=1), that removes the #ifdefed blocks and it clashes with your first patch a bit. FYI, I have rebased your first patch on top of the Pavel's patch: http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc6/patches/39-acpi-video-mode-fix.patch Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fujitsu application panel driver (rev3)
On Fri, 14 Sep 2007 01:30:58 -0400 Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > Hi Stephen, > > On Wednesday 12 September 2007 07:38, Stephen Hemminger wrote: > > This driver supports the application buttons on some Fujitsu Lifebook > > laptops. > > It is based on the earlier apanel driver done by Jochen Eisenger, but > > with many changes. The original driver used ioctl's and a separate > > user space program; see http://apanel.sourceforge.net/tech.php > > This version hooks into the input subsystem so that the normal > > Gnome/KDE shortcuts work without any userspace changes. > > > > The Mail Led is handled via leds class device. > > > > Thank you very much for convering the led to led subsystem. I tried > implementing loadable keymap support in the driver, could you please > try the patch below and if it still works for you then I will apply > it to my tree. > Sorry, you are raising the bar for new drivers, higher than existing code. It is really bad (second system syndrome), if maintainers keep wanting new code to to more than existing drivers. Please take driver AS IS. Go ahead and add loadable key map support, but fix all the other drivers in the tree at the same time that use the existing interface. - 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]PCI:disable resource decode in PCI BAR detection
On Sun, Sep 16, 2007 at 03:13:55PM +0400, Ivan Kokshaysky wrote: > Another possible solution is not to use mmconfig for bar sizing at all, > if it's *that* broken. It would be more complicated though, since it > probably requires changes to all architectures. I don't think it would be that complicated. We could just delay probing for mmconfig until after the pci bus probes are done. No changes to other architectures needed. I'm really disappointed with mmconfig. Here was a great chance to get rid of all the sucky performance problems of the past, and BIOS writers and chipset designers have fucked up the implementation so much that it's now the ugliest method for getting to pci config space. And it's the *only* method of getting to extended config space. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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] Wake up mandatory locks waiter on chmod
On Thu, Sep 13, 2007 at 06:30:43PM +0400, Pavel Emelyanov wrote:
> When the process is blocked on mandatory lock and someone changes
> the inode's permissions, so that the lock is no longer mandatory,
> nobody wakes up the blocked process, but probably should.
I suppose so. Does anyone actually use mandatory locking?
Would it be worth adding a
if (MANDATORY_LOCK(inode))
return;
to the beginning of locks_wakeup_mandatory() to avoid walking the list
of locks in that case? Perhaps setattr is rare enough that this just
isn't worth caring about.
Is there a small chance that a lock may be applied after this check:
> + mandatory = (inode->i_flock && MANDATORY_LOCK(inode));
> +
but early enough that someone can still block on the lock while the file
is still marked for mandatory locking? (And is the inode->i_flock check
there really necessary?)
Well, there are probably worse races in the mandatory locking code.
(For example, my impression is that a mandatory lock can be applied just
after the locks_mandatory_area() checks but before the io actually
completes.)
--b.
> if (inode->i_op && inode->i_op->setattr) {
> error = security_inode_setattr(dentry, attr);
> if (!error)
> @@ -171,8 +173,11 @@ int notify_change(struct dentry * dentry
> if (ia_valid & ATTR_SIZE)
> up_write(&dentry->d_inode->i_alloc_sem);
>
> - if (!error)
> + if (!error) {
> fsnotify_change(dentry, ia_valid);
> + if (mandatory)
> + locks_wakeup_mandatory(inode);
> + }
>
> return error;
> }
> diff --git a/fs/locks.c b/fs/locks.c
> index 83ba887..c0c2281 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1106,7 +1106,8 @@ int locks_mandatory_area(int read_write,
> break;
> if (!(fl.fl_flags & FL_SLEEP))
> break;
> - error = wait_event_interruptible(fl.fl_wait, !fl.fl_next);
> + error = wait_event_interruptible(fl.fl_wait,
> + !fl.fl_next || !__MANDATORY_LOCK(inode));
> if (!error) {
> /*
>* If we've been sleeping someone might have
> @@ -1125,6 +1126,20 @@ int locks_mandatory_area(int read_write,
>
> EXPORT_SYMBOL(locks_mandatory_area);
>
> +void locks_wakeup_mandatory(struct inode *inode)
> +{
> + struct file_lock *fl, **before;
> +
> + lock_kernel();
> + for_each_lock(inode, before) {
> + fl = *before;
> +
> + if (IS_POSIX(fl))
> + locks_wake_up_blocks(fl);
> + }
> + unlock_kernel();
> +}
> +
> /* We already had a lease on this file; just change its type */
> int lease_modify(struct file_lock **before, int arg)
> {
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 035ffda..af0637f 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1483,6 +1483,7 @@ extern struct kset fs_subsys;
>
> extern int locks_mandatory_locked(struct inode *);
> extern int locks_mandatory_area(int, struct inode *, struct file *, loff_t,
> size_t);
> +extern void locks_wakeup_mandatory(struct inode *);
>
> /*
> * Candidates for mandatory locking have the setgid bit set
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression: fireware causes oops during system
On Sunday, 16 September 2007 20:41, Stefan Richter wrote: > (Adding Cc: Rafael, Ingo) > > Pavel Machek wrote: > >> Dmesg with the oops or/and bisection would be good. > > > > Sorry, had to hand-copy. It is oops at virtual adddress 6b6b6b7b -- > > looks like slab poison to me? > > > > EIP is in task_rq_lock, backtrace is > > try_to_wake_up > > highlevel_host_reset > > ohci_irq_handler > > In reverse order, this trace is most certainly > > drivers/ieee1394/ohci1394.c::ohci_irq_handler > drivers/ieee1394/highlevel.c::highlevel_host_reset > drivers/ieee1394/highlevel.c::nodemgr_highlevel.host_reset > == nodemgr_host_reset > kernel/sched.c::wake_up_process(hi->thread); > > with hi->thread being the kthread which executes > drivers/ieee1394/nodemgr.c::nodemgr_host_thread of the ieee1394 core driver. > > The ieee1394 core has two (or more) threads: One nodemgr_host_thread > alias [knodemgrd_*] for each card, and one hpsbpkt_thread alias > [khpsbpkt] for all cards. The knodemgrd should be frozen during suspend > or hibernate, while khpsbpkt should not be frozen in order to let > transactions to go on in the case of saving the hibernation image to a > FireWire disk. > > > Quoting your other post: > > On Tue 2007-09-11 21:45:58, Stefan Richter wrote: > >> Between -rc3 and -rc4: > >> > >>ieee1394: sbp2: fix sbp2_remove_device for error cases > >>a2ee3f9bbb0ce57102dad8928d54f59acdc4b8f7 > >>should not occur in suspend path > > > > Plus I do not have firewire attached disk here, so sbp2 should not be > > used, right? > > Sbp2's host_reset handler would do something if it was loaded even > without any SBP-2 devices attached,but it wouldn't under any > circumstances call try_to_wake_up. Actually with no devices attached it > would simply "iterate" over an empty list. > > >> Between -rc1 and -rc2: > >> > >>ieee1394: sbp2: more correct Kconfig dependencies > >>e4f8cac5e07528f7e0bc21d3682c16c9de993ecb > >>unrelated > >> > >>ieee1394: revert "sbp2: enforce 32bit DMA mapping" > >>a9c2f18800753c82c45fc13b27bdc148849bdbb2 > >>unrelated > >> > >>(not via linux1394-2.6.git) > >>raw1394 __user annotation > >>5b26e64ea39e45802c5736c8261bf8a8704d212f > >>unrelated > >> > >> So it must be something older which was somehow uncovered. > >> Dmesg with the oops or/and bisection would be good. > > > > The others look even more innocent. I wonder if this may have been > > responsible? > > > > commit 831441862956fffa17b9801db37e6ea1650b0f69 > > tree b0334921341f8f1734bdd3243de76d676329d21c > > parent 787d2214c19bcc9b6ac48af0ce098277a801eded > > author Rafael J. Wysocki <[EMAIL PROTECTED]> Tue, 17 Jul 2007 04:03:35 -0700 > > committer Linus Torvalds <[EMAIL PROTECTED]> Tue, 17 > > Jul 2007 10:23:02 -0700 > > > > Freezer: make kernel threads nonfreezable by default Well, I don't think so. nodemgr_host_thread() calls set_freezable() as it should. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
Can E. Acar wrote: There have been complete silence from the leaders of their own community (Linux Kernel developers, FSF, ...) all perhaps used your Regarding "Linux Kernel developers," false. _I_ have posted. ath5k, wireless, and net driver maintainers have all sent emails. License and code fixes have been committed. As for the FSF: It has been repeatedly stated that the FSF has zip to do with this. Nothing. Nada. Zero. Zilch. Linux != FSF. argument to convince themselves that this is not their problem. However, from an outsider point of view, this lack of silence means an agreement to something that is ethically and legally wrong. You are failing to observe that changes have been made in response to criticism. Given that Linux Kernel devs have responded both with code changes and emails, "silence" and "inaction" are provably false. And since the changes go ath5k->linville->me->linus or ath5k->linville->me->davem->linus, I am a step in the approval chain. I do know what I'm talking about. :) 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: iunique() fails to return ino_t (after commit 866b04fccbf125cd)
On Mon, 17 Sep 2007 00:58:54 +0530 "Satyam Sharma" <[EMAIL PROTECTED]> wrote: > [*] BTW, the changelog/patch description of this commit demonstrates > why it is a Bad Thing (tm) to have lengthy [PATCH 0/x] kind of mails > (containing important technical details) preceding a patchset. > > I can only guess as to what happened, but reading the archives of the > original submission of this patchset on LKML, I think Andrew had to > append the contents of the [0/3] mail to the git commit of the [1/3] > patch (so as to not lose all those details and ensure that they got saved > in the git history), with the result that most of the changelog of commit > 866b04fccbf1 has nothing to do with that particular patch at all, but > instead with other commits, that do not even touch that same file (!) > > So guys, please keep "[0/x]" mails short and only as a non-technical > introduction of the patchset. All relevant discussion must come in the > other mails that contain the *real* patches. yup. Actually, when I do the copying of the [0/n] text into [1/n]'s changelog I could add text to the changelogs of [2/n] ... [n/n] mentioning that more details are in the preceding changelog. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] menuconfig: distinguish between selected-by-another options and comments
Hi, On Sun, 16 Sep 2007, Sam Ravnborg wrote: > > On Sun, 16 Sep 2007, Sam Ravnborg wrote: > > > > > But can you take a look at distingushing between non-selectable options > > > due to dependency issues and seleted-by symbols. > > > > Do you have an example in mind? If a symbol is not changable, but still > > visible, a select is usually involved. > > On i86_64 (but I think the arch does not matter). > make defconfig > make menuconfig > > At top-level menu I see: > --- Enable the block layer ---> > > In block/Kconfig we have: > menuconfig BLOCK >bool "Enable the block layer" if EMBEDDED >default y > > If EMBEDDED == n then we see the above. > And this was my first experience with this patch - and it > took me some thoughts to realise it was the "if EMBEDDED" part > that made it look like -*- Indeed, I forgot about this case. Here it's actually the menu entry of a symbol that is forced to be visible, because a child entry is visible. bye, Roman - 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 v3] menuconfig: distinguish between selected-by-another options and comments
Hi, On Sun, 16 Sep 2007, Matej Laitl wrote: > The v2 was maybe more intuitive, but had at least one flaw, where it claimed > the option was selected by another, while it was in fact only made > unchangeable by 'bool "Enable block layer" if EMBEDDED', defaulting to y. The point is that I'm getting more concerned about overloading the interface with nontrivial information. Another direction to consider would be to add this information to the help text, e.g. choose one syntax for nonchangable symbols and then the user can press help to find more detailed information. > > This maximum value is overridden > > by the minimum value, so I wouldn't like it to be exported like this. > > Where exactly does this happen? sym_tristate_within_range() checks whether the new value is ok and sym_calc_value() uses rev_dep to override the value when necessary. > There are cases when maximum < minimum, for > example when you THINKPAD_ACPI, then BACKLIGHT_LCD_SUPPORT. After > that, > BACKLIGHT_CLASS_DEVICE has minimum of 1 (selected by THINKPAD_ACPI) and > maximum > 0 (depends on BACKLIGHT_LCD_SUPPORT, which is n) The actual maximum value is then 1. > The function names are maybe suboptimal, I agree. The variable name is already correct, it's the visibility value of a symbol not its maximum. In the case of the "if EMBEDDED" then individual menu entries can still be visible, if any child entry is visible (see menu_is_visible()). bye, Roman - 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/
iunique() fails to return ino_t (after commit 866b04fccbf125cd)
Hi Jeff, I think commit 866b04fccbf125cd39f2bdbcfeaa611d39a061a8 was wrong, and introduced a regression. The "relevant" changelog [*] of that patch says: > on filesystems w/o permanent inode numbers, i_ino values can be larger > than 32 bits, which can cause problems for some 32 bit userspace programs > on a 64 bit kernel. We can't do anything for filesystems that have > actual >32-bit inode numbers, but on filesystems that generate i_ino > values on the fly, we should try to have them fit in 32 bits. We could > trivially fix this by making the static counters in new_inode and iunique > 32 bits [...] > > [...] > When a 32-bit program that was not compiled with large file offsets does a > stat and gets a st_ino value back that won't fit in the 32 bit field, glibc > (correctly) generates an EOVERFLOW error. We can't do anything about fs's > with larger permanent inode numbers, but when we generate them on the fly, > we ought to try and have them fit within a 32 bit field. > > This patch takes the first step toward this by making the static counters > in these two functions be 32 bits. 1. First and foremost, there was nothing wrong with the existing code that needed to be "fixed" at all, i.e. there was no "problem" to be solved in the first place. As was said, glibc *correctly* returns EOVERFLOW when a userspace application built *without* _FILE_OFFSET_BITS == 64 (i.e. ino_t != __ino64_t) tries to stat(2) a file whose serial number does not fit in the "st_ino" member of struct stat. This behaviour is (1) correct, (2) explicitly mandated by the Single UNIX Specification, and, (3) all userspace programs *must* be prepared to deal with it. [ Should probably mention here that other implementations, such as Solaris, do conform with SUS here. ] 2. The patch has nothing to do with "32-bit userspace on 64-bit kernels" or compatibility modes whatsoever. It is unrelated and tangential that this behaviour is easy to reproduce on the above mentioned setup. Simply put, the issue is that a userspace program built *without* LFS tried to stat(2) a file with serial number > 2**32. Needless to say, this issue must be solved in the userspace program itself (either by (1) defining LFS, or, (2) making it aware of EOVERFLOW), and not in the kernel. 3. Solving a problem at a place where it does not exist naturally leads to other breakage. After 866b04fccbf125cd, iunique() no longer returns an ino_t, but only values <= 2**32, which limits the number of inodes on all filesystems that use that function. Needless to say, this is a *regression* w.r.t. previous kernels before that commit went in. 4. Last but not the least, the sample testcase program that was discussed on LKML last year to show this "problem" was buggy and wrong. A program built without LFS will also suffer EOVERFLOW when stat(2)'ing a file due to other reasons, such as filesize not fitting inside the "st_size" member. Do we propose to "fix" that "problem" in the kernel too ? Of course not! IMHO it's bad to change the kernel's behaviour to avoid buggy userspace programs from seeing standard-mandated errors being returned from stat(2). So please reconsider that patch -- IMHO it clearly wasn't correct. Satyam [*] BTW, the changelog/patch description of this commit demonstrates why it is a Bad Thing (tm) to have lengthy [PATCH 0/x] kind of mails (containing important technical details) preceding a patchset. I can only guess as to what happened, but reading the archives of the original submission of this patchset on LKML, I think Andrew had to append the contents of the [0/3] mail to the git commit of the [1/3] patch (so as to not lose all those details and ensure that they got saved in the git history), with the result that most of the changelog of commit 866b04fccbf1 has nothing to do with that particular patch at all, but instead with other commits, that do not even touch that same file (!) So guys, please keep "[0/x]" mails short and only as a non-technical introduction of the patchset. All relevant discussion must come in the other mails that contain the *real* patches. - 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: kbuild update
On Sun, 16 Sep 2007 08:58:03 -0400 (EDT) "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > On Sun, 16 Sep 2007, Sam Ravnborg wrote: > > > A summary of what is planned to be submitted in next merge window for > > kbuild. > > The shortlog below have additional details but the headlines are: > ... > > o add script to find unused kconfig symbols (try it!) > > based on my experiences with this, unless you filter carefully, you're > going to end up with a *whack* of false positives given the number of > developers who elect to name their local macros starting with a prefix > of "CONFIG_". good luck dealing with *that*. :-) box:/usr/src/linux-2.6.23-rc6> grep -r '^[ ]*#[]*define[ ]*CONFIG_' . | wc -l 415 bah. They're all bugs - The CONFIG_foo namespace is (should be) reserved in kernel coding. - 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] Configurable tap interface MTU
From: "Ed Swierk" <[EMAIL PROTECTED]> Date: Wed, 12 Sep 2007 09:54:35 -0700 > On 9/11/07, Herbert Xu <[EMAIL PROTECTED]> wrote: > > Please make it 65535 without an Ethernet header and 65521 > > with an Ethernet header. > > Here is a revised patch that allows MTUs up to 65535 for tap > interfaces and up to 65521 for tun interfaces. > > (If I set the MTU to 65521 on a tun interface, ping complains "message > too long" when I send a 65521-byte packet; 65520 works okay, though.) Applied to net-2.6.24 Please provide a proper Signed-off-by: line and a full changelog with every patch submission and revision in the future. Thanks. - 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/
