Re: [RFC] LZO de/compression support - take 6
On 5/29/07, Bret Towe <[EMAIL PROTECTED]> wrote: tested this on ppc and its still good is there any reason to bother with a test on amd64? if there is I might be able to get to it tonight Yes, this test is desired on 'take 6' (In future I will append version to patch bz2) Thanks, Nitin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/3] introduce SYS_CLONE_MASK
> Having the kernel not reparent user processes to init is an interesting > idea, especially when those processes have not existed. I'm not > certain that is POSIX complaint and otherwise backwards compatible. It's hard to see how it would work. There has to be some parent PID. The reason using 1 makes sense is that it is always there. Anything >0 and not the PID of some live process could be reused for a new process at some point. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] LZO de/compression support - take 6
On 5/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote: > On 5/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: I have not seen any explanations: - Why did the upstream author write the code that way? - Why are your changes correct? - Why do your changes allow the compiler to produce faster code? The upstream author of the code is available - and he might be able to help you getting answers. No matter whether your changes are incorrect or correct optimizations that should go upstream, in both cases discussing these issues with upstream is the best solution. The changelog I posted along with patch mentions all the changes I made. I thought we will find all problems with this changelog in hand and considering that its just ~500 LOC. But still, ok, asking author himself will be good if he replies. I will mail him detailed changelog and seek his feedback on this. This should answer all of your questions. And testing is nice, but if you broke some case that's outside of your tests you'll never notice. Yes. We cannot come up with exhaustive set of test cases to cover all cases. But assuming that _original_ version is right and taking the chagelog we should be able to verify if the porting is correct. - Nitin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] LZO de/compression support - take 6
On 5/29/07, Bret Towe <[EMAIL PROTECTED]> wrote:
On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Attached is tester code used for testing.
> (developed by Daniel Hazelton -- modified slightly to now use 'take 6'
> version for 'TinyLZO')
>
> Cheers,
> Nitin
>
> On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> > (Using tester program from Daniel)
> >
> > Following compares this kernel port ('take 6') vs original miniLZO code:
> >
> > 'TinyLZO' refers to this kernel port.
> >
> > 1 run averages:
> > 'Tiny LZO':
> >Combined: 61.2223 usec
> >Compression: 41.8412 usec
> >Decompression: 19.3811 usec
> > 'miniLZO':
> >Combined: 66.0444 usec
> >Compression: 46.6323 usec
> >Decompression: 19.4121 usec
> >
> > Result:
> > Overall: TinyLZO is 7.3% faster
> > Compressor: TinyLZO is 10.2% faster
> > Decompressor: TinyLZO is 0.15% faster
> >
>
>
1 run averages:
'Tiny LZO':
Combined: 112.6642 usec
Compression: 56.3321 usec
Decompression: 56.3321 usec
'miniLZO':
Combined: 77.6642 usec
Compression: 56.3416 usec
Decompression: 21.3226 usec
now the interesting bit I thought was the following
[EMAIL PROTECTED]:/usr/src/lzo1x-test-4# ./fulltest
[test_lzo.c::compress (93)] run took 42 microseconds
[test_lzo.c::decompress (127)] run took 20 microseconds
[EMAIL PROTECTED]:/usr/src/lzo1x-test-4# ./tinytest
[test.c::compress (91)] run took 44 microseconds
[test.c::decompress (117)] BUG: lzo1x_decompress has failed ( t == -6 )
[test.c::main (149)] BUG: Decompression routine failure
Did you use x86 for above test? Maybe some problem with testing
script? What data did you use for this test?
- Nitin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Preserve the dirty bit in init_page_buffers
Nick Piggin <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Nick Piggin <[EMAIL PROTECTED]> writes: > >>> However we >>>could still set_page_dirty of a block device page without buffers >>>via an mmap. >> >> >> After the page is made dirty via mmap we have: >> sys_write -> ... -> block_prepare_write -> ... -> create_empty_buffers. > > Yep, that's what I mean. > > >> I suspect that is a pretty rare case but it does indeed seem to exist >> as a problem. > > I think so too. But either we have some misunderstanding of the > codepaths involved, or the author of the comments there didn't > consider this case, so... Which is likely. Which is why I brought up the try_to_free_buffers case. There has been some significant dancing around trying to sort things out and make them race free in this code. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
Thierry Merle a écrit : Mauro Carvalho Chehab a écrit : As Luca pointed, if we add conversion for one driver, we should add for the rest. Instead, it would be better if Jiri sends the decoding and the rescaling stuff as a patch to v4l2-apps/lib, starting the API decoding library. Once we have a library, we can ask the userspace developers to use it for the formats not recognized by their userspace apps. I think it would be better to evaluate existing solutions (eg. libpw). Agreed. Volunteers? Hi Mauro and Markus, Just to summ up what I understood we need: What do we need in userspace, only for v4l (dvb is not concerned): - colorspace translations - filters that be done in hardware if the selected hardware can, otherwise software plugin - decompression algorithm like stk11xx or usbvision (the decompression algorithm is in kernelspace since it is of linear complexity but shall be moved to userspace) Using pwlib will not mean that application developers will use pwlib to decode v4l driver outputs. C bindings are much more popular than C++ bindings and do not prevent object oriented design. Application developers implement their own codecs. As an example, every application do deinterlacing internally or not... Application developers will probably not use pwlib v4l extensions because they will prefer to write adapted codecs for their framework. Much more important for me is to see the actual specification of the needed v4l extensions points, with advice/participation of application/codec developers. As an example, we could empacket frames with a header containing audio/video format as it is done for MPEG streams. Is it possible without breaking the current ABI? Do application developers would cope with that? Thierry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [stable] pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Mon, May 28, 2007 at 09:53:50AM -0700, Linus Torvalds wrote: > > Before we suspend a device, we call the subsystem that that device has > been registered with. Ie, we have code like this: > > if (dev->class && dev->class->suspend) > error = dev->class->suspend(dev, state); > > which was very much designed so that individual devices wouldn't have to > always know - if the upper layer devices for that class can handle these > things, they should. > > Do people actually _do_ this, right now? No. But we do actually have the > infrastructure, and I think we have one or two classes that actually do > use it (at least the "rfkill_class" has a suspend member, dunno how well > this model actually works). > > I think Greg had some patches to make network drivers use this, for > example. Network drivers right now all end up doing stuff that really > doesn't belong in the driver at all when they suspend, and the > infrastructure _should_ just do it for them (ie do all the _network_ > related stuff, as opposed to the actual hardware-related stuff). Yes, I started to work on it, as it is the correct thing to do, but got sidetracked, sorry :( > (Examples of things that we probably _should_ do for network devices on a > class level: > > suspend: > netif_poll_disable() > if (netif_running(dev)) > dev->stop(dev); > > resume: > if (netif_running(dev)) > dev->start(dev); > netif_poll_enable(dev); > > or something similar). I'll try to hack something together later this week along this line and see how it works... 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: Network broken in kernel level.
Wang Penghui wrote: Hello, list, Recently, i have messed up with the follow problem, i have two server both with two ethernet cards. Here are them: [EMAIL PROTECTED] ~]# lspci | grep -i eth 05:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit Ethernet Controller (rev 18) 07:04.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller (rev 05) And they are running MySQL server on both of them. The OS is RHEL 4 with the default kernel 2.6.9-5.ELsmp. These days there are lots of error message comming out in /var/log/message and dmesg. That kernel is very old, you should get the latest RHEL errata update kernel and see if that helps. There have been hundreds of bugfixes in RHEL kernels since that version. -- 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 1/3] Preserve the dirty bit in init_page_buffers
Eric W. Biederman wrote: Nick Piggin <[EMAIL PROTECTED]> writes: However we could still set_page_dirty of a block device page without buffers via an mmap. After the page is made dirty via mmap we have: sys_write -> ... -> block_prepare_write -> ... -> create_empty_buffers. Yep, that's what I mean. I suspect that is a pretty rare case but it does indeed seem to exist as a problem. I think so too. But either we have some misunderstanding of the codepaths involved, or the author of the comments there didn't consider this case, so... -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
Carsten Otte wrote: The current xip stack relies on having struct page behind the memory segment. This causes few impact on memory management, but occupies some more memory. The cramfs patch chose to modify copy on write in order to deal with vmas that don't have struct page behind. So far, Hugh and Linus have shown strong opposition against copy on write with no struct page behind. If this implementation is acceptable to the them, it seems preferable to me over wasting memory. The xip stack should be modified to use this vma flag in that case. I would rather not :P We can copy on write without a struct page behind the source today, no? What is insufficient for the XIP code with the current COW? -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] UDF: coding style conversion - lindent
This changes were made by Lindent script and the second patch fixup it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/3] introduce SYS_CLONE_MASK
"Albert Cahalan" <[EMAIL PROTECTED]> writes: > This has long been rotten. Mind fixing it for us? :-) > > We have N types of thread on M CPUs. Pick something, N or M, > to be at the top level in /proc. The other goes below, in the > per-process task directories. > > You then have either N or M things showing up in ps, not N*M. > > Note that both ps and top can print the CPU number just fine. > Abusing the task name for this is just retarded. This suggests > that the top level should be the type of task, with the lower > level in /proc/*/task being per-CPU and not needing distinct > naming at all. In a lot of ways that is reasonable. However kernel threads don't share signal handling and getting to the point where they could share signal handling would be difficult so we cannot use the generic CLONE_THREAD handling they really are more like individual processes. So at that level the cpu number in the name is just to help tell them apart. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/3] introduce SYS_CLONE_MASK
"Albert Cahalan" <[EMAIL PROTECTED]> writes: > Jan Engelhardt writes: >> On Apr 10 2007 17:47, Jan Engelhardt wrote: >>> On Apr 8 2007 20:57, Oleg Nesterov wrote: > Anyway, re-parenting to swapper breaks pstree, it doesn't show kernel threads. And if ->parent == /sbin/init, we can't remove us from ->children (unless we forbid sub-thread-of-init exec). So the only safe change is set ->exit_state = -1. >>> >>> Then we have to fix pstree and all that. (In fact, I'm >>> trying to patch `ps f` to DTRT ;p) >> >> Done that and the result is that `ps afwx` now looks like: >> >> PID TTY STAT TIME COMMAND >> 2722 ?S 0:00 [lockd] > ... >> 3 ?S< 0:00 [events/0] >> 2 ?SN 0:00 [ksoftirqd/0] >> 1 ?Ss 0:02 init [3] >> 537 ?S> 1600 ?Ss 0:00 \_ /usr/bin/dbus-daemon --system >> 1692 ?Ss 0:00 \_ /sbin/acpid >> 1923 ?Ss 0:00 \_ /sbin/resmgrd > ... >> -if(self_pid==1 && ADOPTED(processes[i]) && forest_type!='u') >> +if(ADOPTED(processes[i]) && forest_type!='u') > > That's not compatible because init's children are now in the > logical place. Since the days of procps-1.x.x or earlier, > such processes have been listed at top level. > > BTW, what does "ps -ejH" do for you, with and without the patch? ps -ejH displays everything. For 2.6.22 we will only have kthreadd as a sibling of init with ppid == 0. Depending on what happens in the evolution of how we start kernel thread we may be able to remove kthreadd and have all kthreads with a ppid of 0, but only time will tell. > I'd be a lot happier about breaking compatibility in this area > if I could get a functional adoption flag. That is, I really > would like to show a process as child of init if it naturally > was created as a child of init. It's less informative to have > fake children showing up the same as real ones. The original > parent PID would do. (BTW, the original parent name and/or > grandparent PID would be great to have) As a bonus, the kernel > could reap these processes more quickly than init can... and > then maybe we can stop caring if init is alive. Having the kernel not reparent user processes to init is an interesting idea, especially when those processes have not existed. I'm not certain that is POSIX complaint and otherwise backwards compatible. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
warning while building module.
hi all while building module i was getting following warning and it terminate module building stage MODPOST 1889 modules WARNING: vmlinux - Section mismatch: reference to .init.text:start_kernel from .text between 'is386' (at offset 0xc0101171) and 'check_x87' WARNING: vmlinux - Section mismatch: reference to .init.text: from .text between 'rest_init' (at offset 0xc0101458) and 'try_name' WARNING: vmlinux - Section mismatch: reference to .init.text:__alloc_bootmem from .text between 'init_gdt' (at offset 0xc010adfb) and 'cpu_init' WARNING: vmlinux - Section mismatch: reference to .init.text:__alloc_bootmem from .text between 'init_gdt' (at offset 0xc010ae11) and 'cpu_init' WARNING: vmlinux - Section mismatch: reference to .init.text:sysenter_setup from .text between 'identify_cpu' (at offset 0xc010b46b) and 'display_cacheinfo' WARNING: vmlinux - Section mismatch: reference to .init.text:mtrr_bp_init from .text between 'identify_cpu' (at offset 0xc010b475) and 'display_cacheinfo' WARNING: vmlinux - Section mismatch: reference to .init.text:trap_init_f00f_bug from .text between 'init_intel' (at offset 0xc010d576) and 'cpuid4_cache_lookup' WARNING: vmlinux - Section mismatch: reference to .init.text: from .text between 'iret_exc' (at offset 0xc02f2c2e) and '_etext' WARNING: vmlinux - Section mismatch: reference to .init.data:initkmem_list3 from .text between 'set_up_list3s' (at offset 0xc0173aff) and 's_start' WARNING: vmlinux - Section mismatch: reference to .init.text:eisa_root_register from .text between 'virtual_eisa_root_init' (at offset 0xc026fecf) and 'cpufreq_unregister_driver' WARNING: vmlinux - Section mismatch: reference to .init.text: from .text between 'iret_exc' (at offset 0xc02f32c8) and '_etext' i was trying to fix with online available patches but does not help out. please cc to me thanks TEJ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH] NFSD: fix uninitialized variable
Hi,
Given what you said above, I don't see gcc, on its best day, will ever
know enough to validate that that variable is indeed always initialized.
So I would vote for silencing it on those grounds.
I agree too. How about this one:
diff -dur linux/fs/nfsd/nfs4acl.c linux.new/fs/nfsd/nfs4acl.c
--- linux/fs/nfsd/nfs4acl.c 2007-05-29 12:28:29.0 +
+++ linux.new/fs/nfsd/nfs4acl.c 2007-05-29 12:30:45.0 +
@@ -183,8 +183,6 @@
summarize_posix_acl(struct posix_acl *acl, struct posix_acl_summary *pas)
{
struct posix_acl_entry *pa, *pe;
- pas->users = 0;
- pas->groups = 0;
pas->mask = 07;
pe = acl->a_entries + acl->a_count;
@@ -229,6 +227,7 @@
int eflag = ((flags & NFS4_ACL_TYPE_DEFAULT) ?
NFS4_INHERITANCE_FLAGS | NFS4_ACE_INHERIT_ONLY_ACE : 0);
+ memset(pas, 0, sizeof(struct posix_acl_summary);
BUG_ON(pacl->a_count < 3);
summarize_posix_acl(pacl, );
Regards
dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Block devices and barriers
On Monday May 21, [EMAIL PROTECTED] wrote:
> Hi,
>
> I'm adding cache flush support to the PS3 disk driver and have a few questions
> related to barriers.
>
> In my driver, I do:
>
> blk_queue_issue_flush_fn(queue, ps3disk_issue_flush);
> blk_queue_ordered(queue, QUEUE_ORDERED_DRAIN_FLUSH,
> ps3disk_prepare_flush);
>
> but I can't find a way to actually trigger the calling of
> ps3disk_issue_flush()
> and ps3disk_prepare_flush().
>
> 1. My prepare_flush_fn() routine should be called from queue_flush(), which
> is
> in turn called by start_ordered().
> start_ordered() is called by blk_do_ordered(), but only if there's no
> barrier (REQ_HARDBARRIER is not set).
> Apart from drivers/block/pktcdvd.c and init_request_from_bio()
> (BIO_RW_BARRIER is set by drivers/md/md.c only?), the only other way
> REQ_HARDBARRIER can be set is in queue_flush(), which is not possible.
BIO_RW_BARRIER is set by various filesystems when mounted with
-o barrier
or
-o barrier=1 (ext3)
See calls to set_buffer_ordered in fs/jbd/commit.c
>
> 2. My issue_flush_fn() should be called from blkdev_issue_flush() (ignoring
> drivers/md). But blkdev_issue_flush() is called by ReiserFS and XFS only.
Yeh, it isn't widely used at the moment.
>
> I read the Block Device chapter in Linux Device Drivers 3rd edition, which
> says
> to check blk_barrier_rq(), but the barrier part seems to be obsolete, as we
> now
> have the prepare_flush_fn parameter of blk_queue_ordered().
>
> Am I missing something? Should I care about barriers?
Yes, you should care about barriers, though it is true that there is
some confusion around them and it might be difficult.
>
> Thanks!
>
> BTW, Documentation/block/barrier.txt seems to be out-of-date. Patch to update
> it is below.
You might like to post this directly to
Tejun Heo <[EMAIL PROTECTED]>
NeilBrown
>
> ---
>
> Documentation/block/barrier.txt is not in sync with the actual code:
> - blk_queue_ordered() no longer has a gfp_mask parameter
> - blk_queue_ordered_locked() no longer exists
> - sd_prepare_flush() looks slightly different
>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
>
> --- a/Documentation/block/barrier.txt
> +++ b/Documentation/block/barrier.txt
> @@ -82,23 +82,12 @@ including draining and flushing.
> typedef void (prepare_flush_fn)(request_queue_t *q, struct request *rq);
>
> int blk_queue_ordered(request_queue_t *q, unsigned ordered,
> - prepare_flush_fn *prepare_flush_fn,
> - unsigned gfp_mask);
> -
> -int blk_queue_ordered_locked(request_queue_t *q, unsigned ordered,
> - prepare_flush_fn *prepare_flush_fn,
> - unsigned gfp_mask);
> -
> -The only difference between the two functions is whether or not the
> -caller is holding q->queue_lock on entry. The latter expects the
> -caller is holding the lock.
> + prepare_flush_fn *prepare_flush_fn);
>
> @q : the queue in question
> @ordered : the ordered mode the driver/device supports
> @prepare_flush_fn: this function should prepare @rq such that it
> flushes cache to physical medium when executed
> [EMAIL PROTECTED] : gfp_mask used when allocating data structures
> - for ordered processing
>
> For example, SCSI disk driver's prepare_flush_fn looks like the
> following.
> @@ -106,9 +95,10 @@ following.
> static void sd_prepare_flush(request_queue_t *q, struct request *rq)
> {
> memset(rq->cmd, 0, sizeof(rq->cmd));
> - rq->flags |= REQ_BLOCK_PC;
> + rq->cmd_type = REQ_TYPE_BLOCK_PC;
> rq->timeout = SD_TIMEOUT;
> rq->cmd[0] = SYNCHRONIZE_CACHE;
> + rq->cmd_len = 10;
> }
>
> The following seven ordered modes are supported. The following table
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- Sony Network and Software Technology Center Europe
> (NSCE)
> [EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
> Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem,
> Belgium
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On May 28, 2007, at 16:38:38, Pavel Machek wrote: Kyle Moffett wrote: I am of the opinion that adding a "name" parameter to the file/ directory create actions would be useful. For example, with such support you could actually specify a type-transition rule conditional on a specific name or substring: named_type_transition sshd_t tmp_t:sock_file prefix "ssh-" ssh_sock_t; Useful options for matching would be "prefix", "suffix", "substr (start,len)". "regex" would be nice but is sorta computationally intensive and would be likely to cause more problems than it solves. Could someone implement this? AFAICT that prevents SELinux from being superset of AppArmor... Doing this should be significantly simpler than whole AA, and hopefully it will end up less ugly, too. Really it would need to extend all action-match items with new "named_" equivalents, and most callbacks would need to be extended to pass in an object name, if available. On the other hand, with such support implemented then the AppArmor policy compilation tools could be transformed into a simple SELinux policy generator. I estimate that the number of new lines of kernel code for such a modified SELinux would be 100x less than the kernel code in AppArmor. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On May 28, 2007, at 06:41:11, Toshiharu Harada wrote: 2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>: If you can't properly manage your labels, then how do you expect any security at all? Please read my message again. I didn't say, "This can never be achieved". I said, "This can not be easily achieved". So you said "(data labels) can not be easily achieved". My question for you is: How do you manage secure UNIX systems without standard UNIX permission bits? Also: If you have problems with data labels then what makes pathname based labels "easier"? If there is something that could be done to improve SELinux and make it more readily configurable then it should probably be done. Permission bits can be checked easily with "ls" command but assuring the correctness of labels are not that easy. I'll try to explain. The correctness of the permission bit for a given file can be judged solely by the result of "ls" command. The correctness of the label, on the other hand, can't be judged without understanding of whole policy including domain transitions. (see the attached figure) I can imagine that once one get the complete SELinux policy, then it is able to modify and maintain it. That's why there are a number of efforts to make modular SELinux policies. A good SELinux policy provides a few core system types and labels which a policy developer needs to understand, as well as some good macros to simplify the human-editable policy files. For instance, in my customized policy a daemon run by an initscript which reads a single config file in /etc needs this policy (Note that I use "_d" as a suffix for process domains instead of the usual "_t"): initrc_daemon(foo_exec_t, foo_d) daemon_config(foo_d, foo_conf_t) Add maybe 2 lines for network port access, another 2 for database files in /var, plus maybe an "iptables" rule or two in your firewall file. I don't say making a complete SELinux policy is impossible, and actually you said you did it. But to be frank, I don't think you are the average level user at all. ;-) Average users are not supposed to be writing security policy. To be honest, even average-level system administrators should not be writing security policy. It's OK for such sysadmins to tweak existing policy to give access to additional web-docs or such, but only expert sysadmin/developers or security professionals should be writing security policy. It's just too damn easy to get completely wrong. I'm very interested in how you can know that you have the correct object labeling (this is my point). Could you tell? I know that I have the correct object labeling because: Do you mind if I add this? 0) I understood the default policy and perfectly understand the every behavior of my system. this is where the difficulties exist. You don't have to understand the entire default policy; that's the point of modular policy. You only have to understand how to _use_ the interfaces of the system policy (which are documented) and how the particular daemon policy is supposed to work. The people developing the core system policy need to understand the inner workings of said policy, but they don't need to understand how the rest of the system works. The core functionality behind this separation is macro interfaces and attributes. By grouping types with attributes it is possible for arbitrary daemon types to categorize themselves under access rules defined by the base policy, and with interfaces the daemons don't really even need to know what those attributes are called. I don't deny DAC at all. If we deny DAC, we can't live with Linux it's the base. MAC can be used to cover the shortages of DAC and Linux's simple user model, that's it. From security point of view, simplicity is always the virtue and the way to go. Inode combined label is guaranteed to be a single at any point time. This is the most noticeable advantage of label-based security. I would argue that pathname-based security breaks the "simplicity is the best virtue (of a security system)" paradigm, because it attributes multiple potentially-conflicting labels to the same piece I have a question for you. With current implementation of SELinux, only one label can be assigned. But there are cases that one object can be used in different context, so I think it might help if SELinux would allow objects to have multiple labels. (I'm not talking about conflicts here) What do you think? This is the whole advantage of SELinux type attributes: you can define a type "var_foo_t" which has a specific list of attributes; rules which accept type specifiers can also accept attribute specifiers as well. If what you want is a label which may be accessed in two different ways, then you declare attributes for each access method and declare a type which has the attributes "filetype", "access1", and "access2"
Network broken in kernel level.
Hello, list, Recently, i have messed up with the follow problem, i have two server both with two ethernet cards. Here are them: [EMAIL PROTECTED] ~]# lspci | grep -i eth 05:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit Ethernet Controller (rev 18) 07:04.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller (rev 05) And they are running MySQL server on both of them. The OS is RHEL 4 with the default kernel 2.6.9-5.ELsmp. These days there are lots of error message comming out in /var/log/message and dmesg. KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1348) KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1348) KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1348) KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1284) KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1284) When it appeared, the network of Marvell card has been broken. It connected but accessable. We have installed the driver of the Marvell card manully with the driver "Driver version: 8.30.2.3 (Dec-14-2005)". I have digged in google for a long time. But unluckly, i haven't got the sulotion. Did i need a kernel upgrade or driver upgrade or anything else? Every response is apperciated. Wang. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS
Peter Williams wrote: Srivatsa Vaddagiri wrote: On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote: I don't think that ignoring cpu affinity is an option. Setting the cpu affinity of tasks is a deliberate policy action on the part of the system administrator and has to be honoured. mmm ..but users can set cpu affinity w/o administrator priveleges .. OK. So you have to assume the users know what they're doing. :-) In reality though, the policy of allowing ordinary users to set affinity on their tasks should be rethought. After more contemplation, I now think I may have gone overboard here. I am now of the opinion that any degradation of overall system performance due to the use of cpu affinity would be confined to the tasks with cpu affinity set. So there's no need to prevent ordinary users from setting cpu affinity on their own processes as any degradation will only affect them. So it goes back to the situation where you have to assume that they know what they're doing and obey their policy. In any case, there's no point having cpu affinity if it's going to be ignored. Maybe you could have two levels of affinity: 1. if set by a root it must be obeyed; and 2. if set by an ordinary user it can be overridden if the best interests of the system dictate. BUT I think that would be a bad idea. This idea is now not just bad but unnecessary. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/3] introduce SYS_CLONE_MASK
Jan Engelhardt writes: On Apr 10 2007 17:47, Jan Engelhardt wrote: On Apr 8 2007 20:57, Oleg Nesterov wrote: Anyway, re-parenting to swapper breaks pstree, it doesn't show kernel threads. And if ->parent == /sbin/init, we can't remove us from ->children (unless we forbid sub-thread-of-init exec). So the only safe change is set ->exit_state = -1. Then we have to fix pstree and all that. (In fact, I'm trying to patch `ps f` to DTRT ;p) Done that and the result is that `ps afwx` now looks like: PID TTY STAT TIME COMMAND 2722 ?S 0:00 [lockd] ... 3 ?S< 0:00 [events/0] 2 ?SN 0:00 [ksoftirqd/0] 1 ?Ss 0:02 init [3] 537 ?S ... -if(self_pid==1 && ADOPTED(processes[i]) && forest_type!='u') +if(ADOPTED(processes[i]) && forest_type!='u') That's not compatible because init's children are now in the logical place. Since the days of procps-1.x.x or earlier, such processes have been listed at top level. BTW, what does "ps -ejH" do for you, with and without the patch? I'd be a lot happier about breaking compatibility in this area if I could get a functional adoption flag. That is, I really would like to show a process as child of init if it naturally was created as a child of init. It's less informative to have fake children showing up the same as real ones. The original parent PID would do. (BTW, the original parent name and/or grandparent PID would be great to have) As a bonus, the kernel could reap these processes more quickly than init can... and then maybe we can stop caring if init is alive. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH] NFSD: fix uninitialized variable
J. Bruce Fields wrote: On Sun, May 27, 2007 at 06:34:42AM -0400, Jeff Garzik wrote: Unlike many of the bogus warnings spewed by gcc, this one actually complains about a real bug: No, the calls to posix_acl_valid() in nfs4_acl_posix_to_nfsv4() ensure that the passed-in acl has ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER entries, and hence that these fields will always be initialized. OK But I don't want anyone else wasting their time on this. Should we cave in and add the initialization here just to shut up gcc? Or would a comment here help? Given what you said above, I don't see gcc, on its best day, will ever know enough to validate that that variable is indeed always initialized. So I would vote for silencing it on those grounds. 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: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
On Monday May 28, [EMAIL PROTECTED] wrote: > On Thu, May 24, 2007 at 05:39:11PM +, Pavel Machek wrote: > > Right. Could we get more helpful message here? 'Filesystem check on > > next boot on AC power'? > > So "(check deferred; on battery)" wasn't explicit enough? I guess I > assumed that users would understand that the opposite of "on battery" > was "on AC power". I guess I could say "(check defferred 'til on AC > power)" if people think it would be clearer. > So when I use my travelling power adapter which I plug into the 12V-DC power in my car, and it delivers DC power to my notebook. My note book tells me that I am using AC power I really think "AC" as the opposite of "battery" is wrong and should be stamped out everywhere, certainly not introduced here. "external power" maybe? Check deferred until system is externally powered. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH] NFSD: fix uninitialized variable
On Sun, May 27, 2007 at 06:34:42AM -0400, Jeff Garzik wrote: > > Unlike many of the bogus warnings spewed by gcc, this one actually > complains about a real bug: No, the calls to posix_acl_valid() in nfs4_acl_posix_to_nfsv4() ensure that the passed-in acl has ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER entries, and hence that these fields will always be initialized. But I don't want anyone else wasting their time on this. Should we cave in and add the initialization here just to shut up gcc? Or would a comment here help? --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/3] introduce SYS_CLONE_MASK
Robin Holt writes: On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote: Robin Holt <[EMAIL PROTECTED]> writes: I would say this is more a benefit than a problem. With a couple of these systems we are testing, the number of kernel threads is far greater than the number of user processes and having pstree not normally show them, but maybe have an option we add later to show them again would be beneficial. Sure. Robin how many kernel thread per cpu are you seeing? 10. This has long been rotten. Mind fixing it for us? :-) We have N types of thread on M CPUs. Pick something, N or M, to be at the top level in /proc. The other goes below, in the per-process task directories. You then have either N or M things showing up in ps, not N*M. Note that both ps and top can print the CPU number just fine. Abusing the task name for this is just retarded. This suggests that the top level should be the type of task, with the lower level in /proc/*/task being per-CPU and not needing distinct naming at all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
On Thu, May 24, 2007 at 05:39:11PM +, Pavel Machek wrote: > Right. Could we get more helpful message here? 'Filesystem check on > next boot on AC power'? So "(check deferred; on battery)" wasn't explicit enough? I guess I assumed that users would understand that the opposite of "on battery" was "on AC power". I guess I could say "(check defferred 'til on AC power)" if people think it would be clearer. > Or maybe keep counting, and when we reach 2x mount-count-limit, > force a fsck, battery power or not? We do that already. It's just tough to make that all fit on an 80 status message. :-) - 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: [patch] Add the device IDs f or AMD/ATI SB700
Hi all,
Since I am a junior linux developing engineer, I really appreciate that you
tell me these informations,
Thanks for your help!
Brs,
Henry
-Original Message-
From: Bartlomiej Zolnierkiewicz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 4:17 AM
To: Jeff Garzik
Cc: Henry Su; [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [patch] Add the device IDs for AMD/ATI SB700
Hi,
Sorry for the late reply and thanks to Jeff for stepping in. :)
Since Jeff covered both status of your patches and administrative issues
I would only like to add one small hint for people adding support for
multi-function PCI chipsets (with multiple PCI device IDs):
It makes sense to put addition of _all_ new PCI IDs into the first patch
of the series and send it to PCI Maintainer (Hi Greg). This should make
all other patches from the series independent of each other (in the usual
case I'm not talking about all crazy scenarios here). After the patch
with PCI IDs gets applied upstream you may now send all other patches to
the respective maintainers without worrying about inter-patch dependencies
and without maintainers worrying about your patches not applying cleanly.
IIRC Intely guys are using this process when adding support for their new
chipsets and it works smoothly.
[ Yep, this process is the exception from the general "patch shouldn't add
unused code" rule but the amount of _temporarily_ unused stuff is _minimal_
and doing it this way saves a lot of time for all parties involved. ]
PS Greg/Jeff If I'm totally wrong on this please correct me...
Thanks,
Bart
On Friday 25 May 2007, Jeff Garzik wrote:
> Henry Su wrote:
> > I check the latest kernel source code with git, and find out that the
> > SMBus patch has not been applied yet,
>
> Correct. When you don't see a patch in the upstream git tree
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> then the next step is consult the MAINTAINERS file, and determine to
> whom you should send a follow-up patch, or simply contact about the
> status of a patch you just sent. In this case, SMBus is in drivers/i2c
> sub-directory, which leads us to find in MAINTAINERS,
>
> I2C SUBSYSTEM
> P: Jean Delvare
> M: [EMAIL PROTECTED]
> L: [EMAIL PROTECTED]
> T: quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
> S: Maintained
>
> That tells us the maintainer of the subsystem, and also ("T:") an
> external reference (a tree) to where the maintainer posts accepted
> patches, prior to sending them upstream.
>
> So for SMBus, you should make sure your SMBus changes appear in Jean
> Delvare's quilt tree. If they do not, create a new patch and send it to
> Jean and CC [EMAIL PROTECTED] and [EMAIL PROTECTED]
>
>
> > and the patch for IDE has not been applied completely.one more device
> > id should be added to pata_atiixp.c,
> > l list the patch as following, or you can fetch it from the attached file,
> > could you please apply this for me?
>
> Actually it has been applied -- the part that I maintain (drivers/ata/*)
> is currently stored in a secondary tree, as described above. Your patch
> has been stored on the 'upstream' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
> Currently, the upstream Linux kernel is only accepting bug fixes. I
> merge ATA bug fixes (and sometimes simple PCI ID additions) into
> libata-dev.git#upstream-fixes during this phase of development. These
> changes are sent upstream in 24-48 hours, to ensure that they will be
> included in the next release (kernel 2.6.22).
>
> All other ATA changes are merged into libata-dev.git#upstream. When
> Linus releases kernel 2.6.22, the "merge window" opens, allowing
> non-bug-fix changes to be submitted upstream. When the merge window
> opens, I submit everything in libata-dev.git#upstream to Linus and
> Andrew Morton for inclusion in the official upstream kernel tree.
>
> That is our development process in a nutshell.
>
> The kernel development process is conducted entirely via email, so you
> see why it is so important to learn how to email patches in the proper
> format.
>
> 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: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS
On 5/28/07, Peter Williams <[EMAIL PROTECTED]> wrote: In any case, there's no point having cpu affinity if it's going to be ignored. Maybe you could have two levels of affinity: 1. if set by a root it must be obeyed; and 2. if set by an ordinary user it can be overridden if the best interests of the system dictate. BUT I think that would be a bad idea. Something like that already exists (at least for controlling the bounding set of allowed cpus) via cpusets. Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add a trivial patch style checker
On 28/05/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote: ... diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index a417b25..23637e8 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -118,7 +118,21 @@ then only post say 15 or so at a time and wait for review and integration. ... -8) Name your kernel version. +9) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. If omitted, we could assume it default to the latest linus git tree. -10) Include PATCH in the subject +11) Include PATCH in the subject Due to high e-mail traffic to Linus, and to linux-kernel, it is common convention to prefix your subject line with [PATCH]. This lets Linus or use "patch", to be easier to read. -- Qi Yong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]Multi-threaded Initcall with dependence support
On Tuesday 29 May 2007 06:52, Randy Dunlap wrote: > On Mon, 28 May 2007 15:03:10 +0800 Yang Sheng wrote: > > Why we need this: > > > > It can speed up the calling of initcalls, especially useful for some > > embed device. > > Can you give concrete example(s) of why we need this? > Any real configs/hardware where it helps and how much it helps. > We didn't got the precise data at hand now, because we should build a complete stable initcall dependence relationship for it, but we can't do it now. But we have done a relative stable test in a common x86_64 machine, with 2 threads and one dependence relation(pnpacpi_init depends on pnp_init and acpi_init). The result is the time spending on initcall calling reducing from about _5s_ to _2s_ (make the kernel with the defconfig). We analyzed the dmesg and found the most of time was save by run ide_generic_init and piix_init in parallel. Of course the dependence in the test case is not sufficient, but the effect is shown. We think this patch would be very useful in some embed deviced which requires fast boot speed. Some server may benefit too because of it's long time for device initiation. > > General: > 1/ Patch has 12 lines with trailing whitespace. Please chop those > off (always). > 2/ Try to keep sources lines < 80 characters. > 3/ Read & use Documentation/CodingStyle, Documentation/SubmittingPatches, > and Documentation/SubmitChecklist. > Thanks for advise! Next time I will be more careful on coding style and check the patch following the document above. The patch below is a prototype now. Some problem can't be solve in current stage, like the map function's algorithm complexity is O(n^2). I have another method for this but require some duplicate name initcall's rename. Thanks! > > Idea: > > > > 1. The initcall can indicate a executing sequence by using the a > > macro(initcall_depend()) in case of causing dependence problem in > > multi-threaded running. Multi dependences is also allowed. > > 2. Ensure the calling of initcalls in the same layer would be completed > > before the next layers' calling. > > > > Usage: > > You can indicate that initcall A must be run after initcall B by calling > > the macro in A's file: > > > > initcall_depend(A, B); > > > > Means initcall A must run after initcall B finish executing(A depends on > > B). > > > > Take notice of that if you declare A depends on B and C, you must put > > these together as (the sequences is not important): > > > > initcall_depend(A, B); > > initcall_depend(A, C); > > > > The detail of method: > > > > A new section called .initcall.depend was added to > > arch/xxx/kernel/vmlinux.lds.S to indicate the dependence relationship. A > > struct called initcall_depend_t stored the relationship between A and B, > > and was stored in section .initcall.depend. > > > > Because all the dependence of A are put together, and the sequences of > > initcall_depend_t was decided in linker order as initcall itself did. > > When A is going to run, we can check if A would depend on others by > > checking the point indicate the current item in dependence table. If the > > field "call" of initcall_depend_t point to A, we know that A is depend on > > something and get the prev_addr of the struct to find what it depends on. > > The field "prev_addr" point to somewhere in .initcall.init section to > > indicate the address(also the order) of depended initcall, so it can be > > used to find out whether other threads complete executing of the depended > > initcall. If the current point of the thread executing is smaller than > > prev_addr(it means some thread not completed executing, not only this > > thread), we'll wait, otherwise we can continue to check next thread. If > > all the thread is ok, we will run the initcall and go to the next one. > > > > This method is not very precision(for we may have to wait even when the > > initcall was completed but not all the other pass it), but easy to > > implement. > > > > I provide two method to get the dependence relationship, the following > > code contains the one which is more flexibly but less efficiency. > > > > The downside of this patch is every driver must explictly indicate its > > dependence, please tell if this is acceptable. Any suggestions and > > comments are welcome. > > > > Thanks. > > > > > > > > arch/x86_64/kernel/vmlinux.lds.S |6 + > > include/linux/init.h | 16 +++ > > init/main.c | 257 > > +++-- 3 files changed, 237 insertions(+), > > 42 deletions(-) > > > > diff --git a/arch/x86_64/kernel/vmlinux.lds.S > > b/arch/x86_64/kernel/vmlinux.lds.S > > index dbccfda..355c8b6 100644 > > --- a/arch/x86_64/kernel/vmlinux.lds.S > > +++ b/arch/x86_64/kernel/vmlinux.lds.S > > @@ -167,6 +167,12 @@ SECTIONS > > INITCALLS > >} > >__initcall_end = .; > > + . = ALIGN(16); > > + __initcall_depend_start = .; > > + .initcall.depend : AT(ADDR(.initcall.depend) -
Re: [PATCH 1/2] UDF: coding style conversion - lindent
On Mon, May 28, 2007 at 06:30:38PM +0400, Cyrill Gorcunov wrote:
>This patch converts UDF coding style to kernel
>coding style using Lindent.
>
>Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
>---
>
> fs/udf/balloc.c| 709 ---
> fs/udf/crc.c | 19 +-
> fs/udf/dir.c | 132 ++---
> fs/udf/directory.c | 207
> fs/udf/ecma_167.h | 875 +---
> fs/udf/file.c | 114 ++--
> fs/udf/fsync.c |4 +-
> fs/udf/ialloc.c| 69 ++--
> fs/udf/inode.c | 1494 ---
> fs/udf/lowlevel.c | 25 +-
> fs/udf/misc.c | 172 +++---
> fs/udf/namei.c | 720 +++
> fs/udf/osta_udf.h | 239
> fs/udf/partition.c | 273 ++
> fs/udf/super.c | 1630
> fs/udf/symlink.c | 56 +-
> fs/udf/truncate.c | 230 +
> fs/udf/udf_i.h |2 +-
> fs/udf/udf_sb.h|6 +-
> fs/udf/udfdecl.h | 106 +++--
> fs/udf/udfend.h|2 +-
> fs/udf/udftime.c | 93 ++--
> fs/udf/unicode.c | 299 +--
> 23 files changed, 3812 insertions(+), 3664 deletions(-)
>
>diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
>index 4cec910..ef48d09 100644
>--- a/fs/udf/balloc.c
>+++ b/fs/udf/balloc.c
>@@ -41,18 +41,17 @@
> #define uint(x) xuint(x)
> #define xuint(x) __le ## x
>
>-static inline int find_next_one_bit (void * addr, int size, int offset)
>+static inline int find_next_one_bit(void *addr, int size, int offset)
> {
>- uintBPL_t * p = ((uintBPL_t *) addr) + (offset / BITS_PER_LONG);
>- int result = offset & ~(BITS_PER_LONG-1);
>+ uintBPL_t *p = ((uintBPL_t *) addr) + (offset / BITS_PER_LONG);
>+ int result = offset & ~(BITS_PER_LONG - 1);
> unsigned long tmp;
>
> if (offset >= size)
> return size;
> size -= result;
>- offset &= (BITS_PER_LONG-1);
>- if (offset)
>- {
>+ offset &= (BITS_PER_LONG - 1);
>+ if (offset) {
> tmp = leBPL_to_cpup(p++);
> tmp &= ~0UL << offset;
> if (size < BITS_PER_LONG)
>@@ -62,8 +61,7 @@ static inline int find_next_one_bit (void * addr, int size,
>int offset)
> size -= BITS_PER_LONG;
> result += BITS_PER_LONG;
> }
>- while (size & ~(BITS_PER_LONG-1))
>- {
>+ while (size & ~(BITS_PER_LONG - 1)) {
> if ((tmp = leBPL_to_cpup(p++)))
> goto found_middle;
> result += BITS_PER_LONG;
>@@ -72,17 +70,18 @@ static inline int find_next_one_bit (void * addr, int
>size, int offset)
> if (!size)
> return result;
> tmp = leBPL_to_cpup(p);
>-found_first:
>- tmp &= ~0UL >> (BITS_PER_LONG-size);
>-found_middle:
>+ found_first:
>+ tmp &= ~0UL >> (BITS_PER_LONG - size);
>+ found_middle:
I doubt about this change. First, it seems that you replace a tab with
whitespaces. Second, IMO, the labels should not be aligned with the statements.
> return result + ffz(~tmp);
> }
>
> #define find_first_one_bit(addr, size)\
> find_next_one_bit((addr), (size), 0)
>
>-static int read_block_bitmap(struct super_block * sb,
>- struct udf_bitmap *bitmap, unsigned int block, unsigned long bitmap_nr)
>+static int read_block_bitmap(struct super_block *sb,
>+ struct udf_bitmap *bitmap, unsigned int block,
>+ unsigned long bitmap_nr)
> {
> struct buffer_head *bh = NULL;
> int retval = 0;
>@@ -92,38 +91,39 @@ static int read_block_bitmap(struct super_block * sb,
> loc.partitionReferenceNum = UDF_SB_PARTITION(sb);
>
> bh = udf_tread(sb, udf_get_lb_pblock(sb, loc, block));
>- if (!bh)
>- {
>+ if (!bh) {
> retval = -EIO;
> }
> bitmap->s_block_bitmap[bitmap_nr] = bh;
> return retval;
> }
>
>-static int __load_block_bitmap(struct super_block * sb,
>- struct udf_bitmap *bitmap, unsigned int block_group)
>+static int __load_block_bitmap(struct super_block *sb,
>+ struct udf_bitmap *bitmap,
>+ unsigned int block_group)
> {
> int retval = 0;
> int nr_groups = bitmap->s_nr_groups;
>
>- if (block_group >= nr_groups)
>- {
>- udf_debug("block_group (%d) > nr_groups (%d)\n", block_group,
>nr_groups);
>+ if (block_group >= nr_groups) {
>+ udf_debug("block_group (%d) > nr_groups (%d)\n", block_group,
>+nr_groups);
> }
>
> if (bitmap->s_block_bitmap[block_group])
> return block_group;
>- else
>- {
>- retval = read_block_bitmap(sb, bitmap, block_group,
>block_group);
>+ else {
>+ retval =
>+ read_block_bitmap(sb, bitmap, block_group, block_group);
> if (retval < 0)
> return
Re: [PATCH] libata: implement ata_wait_after_reset()
Tejun Heo wrote: - msleep(150); + /* wait a while before checking status */ + ata_wait_after_reset(ap, deadline); [...] - msleep(150); + /* wait a while before checking status */ + ata_wait_after_reset(ap, deadline); /* Before we perform post reset processing we want to see if * the bus shows 0xFF because the odd clown forgets the D7 @@ -3543,8 +3583,8 @@ int sata_std_hardreset(struct ata_port * return 0; } - /* wait a while before checking status, see SRST for more info */ - msleep(150); + /* wait a while before checking status */ + ata_wait_after_reset(ap, deadline); rc = ata_wait_ready(ap, deadline); [...] - msleep(150); + /* wait a while before checking status */ + ata_wait_after_reset(ap, deadline); /* Before we perform post reset processing we want to see if * the bus shows 0xFF because the odd clown forgets the D7 Index: work/drivers/ata/sata_inic162x.c === --- work.orig/drivers/ata/sata_inic162x.c +++ work/drivers/ata/sata_inic162x.c @@ -446,7 +446,7 @@ static int inic_hardreset(struct ata_por struct ata_taskfile tf; /* wait a while before checking status */ - msleep(150); + ata_wait_after_reset(ap, deadline); rc = ata_wait_ready(ap, deadline); [...] The main thing that bothers me is not the increase in delay, but the fact that this create converts a delay/Status-poll sequence into a delay/Status-poll/Status-poll sequence. ata_wait_after_reset() immediately before ata_wait_ready() seems highly redundant. Why not just poll Status once? 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] add a trivial patch style checker
Andy Whitcroft <[EMAIL PROTECTED]> writes:
> +
> +# no BUG() or BUG_ON()
> + if ($line =~ /\b(BUG|BUG_ON)\b/) {
> + print "Try to use WARN_ON & Recovery code rather than
> BUG() or BUG_ON()\n";
Just outlawing BUG_ON doesn't seem like a good idea to me. We'll just end
up with lots of untested and likely buggy recovery code or no asserts. Both
would be bad.
> +#need space before brace following if, while, etc
> + if($line=~/\(.*\){/) {
> + print ("need a space before the brace\n");
> + print "$herecurr";
> + $clean = 0;
> + }
> +
> +#gotos aren't indented
You mean goto labels? Surely goto statements are to be indented.
Confusing message
> + if($line=~/^\s*[A-Za-z\d_]+:/ and !($line=~/^\s*default:/)){
> + print "Gotos should not be indented\n";
> + print "$herecurr";
> + $clean = 0;
> + }
emacs generates one space label in front of a goto label. I wouldn't
outlaw this.
> +# don't include
It would be probably better to define some syntax that makes it possible
to auto extract those from feature-removal-schedule.txt. Otherwise
long term this will become messy.
Possible further checks that might make sense:
- panic() anywhere in drivers/*
- externs in .c files without asmlinkage
- general checking that everything in a fully visible {} block is the right
indentation
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v14
Li Yu wrote: But as I observe by cat /proc/sched_debug (2.6.21.1, UP, RHEL4), I found the all waiting fields often are more than zero, or less than zero. IMHO, the sum of task_struct->wait_runtime just is the denominator of all runnable time in some ways, is it right? if so, increasing the sum of wait_runtime just make scheduling decision more precise. so what's meaning for keeping the wait_runtime is zero-sum? Forget it pls, here I am wrong, sorry for pestering. Good luck - Li Yu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: software suspend doesn't work with 2.6.22-rc3
On Mon, May 28, 2007 at 08:21:29PM +0200, Rafael J. Wysocki wrote:
>
> Well, it looks like we have to fix this one separately.
>
> Can you please tell me what to do to make cryptd run?
If you build it as a module then just loading it should be sufficient.
If you have it built-in then it should always be there.
Let me know when you guys have a final patch.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS
Srivatsa Vaddagiri wrote: On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote: I don't think that ignoring cpu affinity is an option. Setting the cpu affinity of tasks is a deliberate policy action on the part of the system administrator and has to be honoured. mmm ..but users can set cpu affinity w/o administrator priveleges .. OK. So you have to assume the users know what they're doing. :-) In reality though, the policy of allowing ordinary users to set affinity on their tasks should be rethought. In any case, there's no point having cpu affinity if it's going to be ignored. Maybe you could have two levels of affinity: 1. if set by a root it must be obeyed; and 2. if set by an ordinary user it can be overridden if the best interests of the system dictate. BUT I think that would be a bad idea. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stuff ready to be deleted?
On Monday 28 May 2007 16:52:07 Robert P. J. Day wrote: > On Mon, 28 May 2007, Oliver Pinter wrote: > > + open sound system > > yeah, that one's so obvious, i don't even list it anymore. :-) i'm > assuming adrian's going to deal with that when the time comes. > > rday And I thought OSS was being kept around until all the hardware it drives properly is also supported by ALSA. Last time this one came up there were still more than 5 items on the list of OSS supported hardware that wasn't covered under ALSA - and the list was likely longer. DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix potential memory leak in tipc_named_node_up()
On 2007.05.28 22:58:08 +0200, Jesper Juhl wrote:
> There seems to be a memory leak in net/tipc/name_distr.c::tipc_named_node_up()
>
> The function, with comments, is this :
>
> void tipc_named_node_up(unsigned long node)
> {
> struct publication *publ;
> struct distr_item *item = NULL;
> struct sk_buff *buf = NULL;
> u32 left = 0;
> u32 rest;
> u32 max_item_buf;
>
> read_lock_bh(_nametbl_lock);
> max_item_buf = TIPC_MAX_USER_MSG_SIZE / ITEM_SIZE;
> max_item_buf *= ITEM_SIZE;
> rest = publ_cnt * ITEM_SIZE;
>
> list_for_each_entry(publ, _root, local_list) {
> -> If we stop processing here after doing 1, 2 & 3 below we end up at (4)
> (below).
> if (!buf) {
> left = (rest <= max_item_buf) ? rest : max_item_buf;
> rest -= left;
> buf = named_prepare_buf(PUBLICATION, left, node);
> -> (1) here we allocate memory and store a pointer to it in 'buf'.
>
> if (!buf) {
> -> (2) This test needs to fail, meaning we did allocate some memory.
> warn("Bulk publication distribution
> failure\n");
> goto exit;
> }
> item = (struct distr_item *)msg_data(buf_msg(buf));
> }
> publ_to_item(item, publ);
> item++;
> left -= ITEM_SIZE;
> if (!left) {
> -> (3) If this test fails we loop and do nothing to 'buf'.
> msg_set_link_selector(buf_msg(buf), node);
> dbg("tipc_named_node_up: sending publish msg to "
> "<%u.%u.%u>\n", tipc_zone(node),
> tipc_cluster(node), tipc_node(node));
> tipc_link_send(buf, node, node);
> buf = NULL;
> }
> }
> exit:
> read_unlock_bh(_nametbl_lock);
> -> (4) here we return without freeing 'buf' - memory leak.
> }
>
> Luckily this is easy to fix, since we can only leave the function with 'buf'
> either set to NULL or (in the leak case) set to a valid address, and since
> kfree() handles being passed NULL gracefully we can simply kfree(buf) just
> before we leave the function.
Actually, I don't think that there's a leak.
publ_cnt: Number of items in the list
rest = publ_cnt * ITEM_SIZE
max_item_buf = n * ITEM_SIZE (Buffer can hold n elements at most)
1)
If publ_cnt <= n, "rest" becomes 0 and "left" becomes publ_cnt * ITEM_SIZE,
so for the last iteration "left" becomes 0 and "buf" is freed.
2)
And if publ_cnt > n, "left" becomes 0 in the nth iteration. As "rest"
already got decrement by n * ITEM_SIZE, you now got:
rest = (publ_cnt - n) * ITEM_SIZE
Then after 2*n iterations:
rest = (publ_cnt - 2*n) * ITEM_SIZE
and so on, until publ_cnt - m*n < n
At that point, "left" becomes (publ_cnt - m*n) * ITEM_SIZE, and there are
also (publ_cnt - m*n) iterations left, so "left" again becomes 0 in the
last iteration and "buf" is freed.
Besides that, is it valid to call kfree() on a buffer allocated by
alloc_skb()?
Thanks,
Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ide_in_drive_list(): "ALL" is not a wildcard anymore.
This removes the support to treat "ALL" as a wildcard for firmware revision. This is made a separate patch, as it will break out-of-tree ide drivers that feed its own table that uses "ALL" as the wildcard to ide_in_drive_list(). Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- * This is a respin of earlier "3/3 Make ide dma blacklist handling a bit saner." drivers/ide/ide-dma.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c index 230ea12..3107b5e 100644 --- a/drivers/ide/ide-dma.c +++ b/drivers/ide/ide-dma.c @@ -148,7 +148,6 @@ int ide_in_drive_list(struct hd_driveid *id, const struct drive_list_entry *driv for ( ; drive_table->id_model ; drive_table++) if ((!strcmp(drive_table->id_model, id->model)) && (!drive_table->id_firmware || -!strcmp(drive_table->id_firmware, "ALL") || /* to be removed later */ strstr(id->fw_rev, drive_table->id_firmware))) return 1; return 0; -- 1.5.2.86.g99b5-dirty - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mips au1xxx_ide.h: use NULL as firmware-revision wildcard.
This updates the DMA whitelist in MIPS specific au1xxx ide
driver to use NULL instead of "ALL" as the wildcard.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
* This is a respin of earlier "3/3 Make ide dma blacklist handling a bit
saner."
include/asm-mips/mach-au1x00/au1xxx_ide.h | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/asm-mips/mach-au1x00/au1xxx_ide.h
b/include/asm-mips/mach-au1x00/au1xxx_ide.h
index 8fcae21..4663e8b 100644
--- a/include/asm-mips/mach-au1x00/au1xxx_ide.h
+++ b/include/asm-mips/mach-au1x00/au1xxx_ide.h
@@ -88,26 +88,26 @@ static const struct drive_list_entry dma_white_list [] = {
/*
* Hitachi
*/
-{ "HITACHI_DK14FA-20", "ALL" },
-{ "HTS726060M9AT00" , "ALL" },
+{ "HITACHI_DK14FA-20", NULL},
+{ "HTS726060M9AT00" , NULL},
/*
* Maxtor
*/
-{ "Maxtor 6E040L0" , "ALL" },
-{ "Maxtor 6Y080P0" , "ALL" },
-{ "Maxtor 6Y160P0" , "ALL" },
+{ "Maxtor 6E040L0" , NULL},
+{ "Maxtor 6Y080P0" , NULL},
+{ "Maxtor 6Y160P0" , NULL},
/*
* Seagate
*/
-{ "ST3120026A" , "ALL" },
-{ "ST320014A" , "ALL" },
-{ "ST94011A", "ALL" },
-{ "ST340016A" , "ALL" },
+{ "ST3120026A" , NULL},
+{ "ST320014A" , NULL},
+{ "ST94011A", NULL},
+{ "ST340016A" , NULL},
/*
* Western Digital
*/
-{ "WDC WD400UE-00HCT0" , "ALL" },
-{ "WDC WD400JB-00JJC0" , "ALL" },
+{ "WDC WD400UE-00HCT0" , NULL},
+{ "WDC WD400JB-00JJC0" , NULL},
{ NULL , NULL}
};
@@ -116,9 +116,9 @@ static const struct drive_list_entry dma_black_list [] = {
/*
* Western Digital
*/
-{ "WDC WD100EB-00CGH0" , "ALL" },
-{ "WDC WD200BB-00AUA1" , "ALL" },
-{ "WDC AC24300L", "ALL" },
+{ "WDC WD100EB-00CGH0" , NULL},
+{ "WDC WD200BB-00AUA1" , NULL},
+{ "WDC AC24300L", NULL},
{ NULL , NULL}
};
#endif
--
1.5.2.86.g99b5-dirty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ide_in_drive_list(): accept NULL as the wildcard for firmware revision.
Earlier, the matching of (model,rev) in ide-dma black/white list
handling was to consider "ALL" in the table to match any
revision. This makes NULL to be also an accepted wildcard, and
changes the entries of tables in ide-dma.c to use NULL.
The code still accepts "ALL" as the wildcard, in order to keep
any out-of-tree ide driver that feeds its own table that uses
"ALL" as the wildcard to ide_in_drive_list() function from
breaking.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
* This is a respin of earlier "3/3 Make ide dma blacklist handling a bit
saner."
drivers/ide/ide-dma.c | 67 +
1 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
index ead141e..230ea12 100644
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -91,45 +91,45 @@
static const struct drive_list_entry drive_whitelist [] = {
- { "Micropolis 2112A", "ALL" },
- { "CONNER CTMA 4000", "ALL" },
- { "CONNER CTT8000-A", "ALL" },
- { "ST34342A", "ALL" },
+ { "Micropolis 2112A", NULL},
+ { "CONNER CTMA 4000", NULL},
+ { "CONNER CTT8000-A", NULL},
+ { "ST34342A", NULL},
{ NULL , NULL}
};
static const struct drive_list_entry drive_blacklist [] = {
- { "WDC AC11000H", "ALL" },
- { "WDC AC22100H", "ALL" },
- { "WDC AC32500H", "ALL" },
- { "WDC AC33100H", "ALL" },
- { "WDC AC31600H", "ALL" },
+ { "WDC AC11000H", NULL},
+ { "WDC AC22100H", NULL},
+ { "WDC AC32500H", NULL},
+ { "WDC AC33100H", NULL},
+ { "WDC AC31600H", NULL},
{ "WDC AC32100H", "24.09P07" },
{ "WDC AC23200L", "21.10N21" },
- { "Compaq CRD-8241B", "ALL" },
- { "CRD-8400B" , "ALL" },
- { "CRD-8480B", "ALL" },
- { "CRD-8482B", "ALL" },
- { "CRD-84" , "ALL" },
- { "SanDisk SDP3B" , "ALL" },
- { "SanDisk SDP3B-64", "ALL" },
- { "SANYO CD-ROM CRD", "ALL" },
- { "HITACHI CDR-8" , "ALL" },
- { "HITACHI CDR-8335", "ALL" },
- { "HITACHI CDR-8435", "ALL" },
- { "Toshiba CD-ROM XM-6202B" , "ALL" },
- { "TOSHIBA CD-ROM XM-1702BC", "ALL" },
- { "CD-532E-A" , "ALL" },
- { "E-IDE CD-ROM CR-840","ALL" },
- { "CD-ROM Drive/F5A", "ALL" },
- { "WPI CDD-820","ALL" },
- { "SAMSUNG CD-ROM SC-148C", "ALL" },
- { "SAMSUNG CD-ROM SC", "ALL" },
- { "ATAPI CD-ROM DRIVE 40X MAXIMUM", "ALL" },
- { "_NEC DV5800A", "ALL" },
+ { "Compaq CRD-8241B", NULL},
+ { "CRD-8400B" , NULL},
+ { "CRD-8480B", NULL},
+ { "CRD-8482B", NULL},
+ { "CRD-84" , NULL},
+ { "SanDisk SDP3B" , NULL},
+ { "SanDisk SDP3B-64", NULL},
+ { "SANYO CD-ROM CRD", NULL},
+ { "HITACHI CDR-8" , NULL},
+ { "HITACHI CDR-8335", NULL},
+ { "HITACHI CDR-8435", NULL},
+ { "Toshiba CD-ROM XM-6202B" , NULL},
+ { "TOSHIBA CD-ROM XM-1702BC", NULL},
+ { "CD-532E-A" , NULL},
+ { "E-IDE CD-ROM CR-840",NULL},
+ { "CD-ROM Drive/F5A", NULL},
+ { "WPI CDD-820",NULL},
+ { "SAMSUNG CD-ROM SC-148C", NULL},
+ { "SAMSUNG CD-ROM SC", NULL},
+ { "ATAPI CD-ROM DRIVE 40X MAXIMUM", NULL},
+ { "_NEC DV5800A", NULL},
{ "SAMSUNG CD-ROM SN-124", "N001" },
- { "Seagate STT2A", "ALL" },
+ { "Seagate STT2A", NULL },
{ NULL , NULL}
};
@@ -147,8 +147,9 @@ int ide_in_drive_list(struct hd_driveid
Re: [PATCH 3/3] Make ide dma blacklist handling a bit saner.
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> writes: > The change itself looks good but IMO it is worth doing it before patch #2/3 > (it would also make it possible for me to merge this patch immediately). Yes, I should have considered that the earlier #2/3 needs coordination between you and Jeff. > When it comes to patch #2 - Alan's comment may be a bit harsh but he seems > to be right - there should be a common library-like file (ata-blacklist.c > or ata-quirks.c or whatever name you like) containing ata_device_blacklist[]. > > This would require slight modification of ide_in_drive_list() to teach > it about ATA_HORKAGE_DMA ... Please also note that is used by > both > IDE and libata so it should be a good place to put struct ata_blacklist_entry > and ATA_HORKAGE_* macros. Thanks for the hint. Alan is correct to point out that I cheated. ;-) If I understand correctly, the change would involve: - create a new file that has ata_device_blacklist[] whose type is "struct ata_blacklist_entry" (i.e. matches libata-core), by separating the table out of ata/libata-core.c. Q1. should that file go to drivers/ata/ or drivers/ide/? - make that file depended on when either libata and/or IDE is selected. Q2. Kconfig dependency rule is needed for this, perhaps. How should that look like? - some out-of-tree drivers might be using ide_in_drive_list() and relying on it to take "struct drive_list_entry"; create a new function, ide_in_device_list(), that takes "struct ata_blacklist_entry" as its parameter. Q3. Is the 'out-of-tree drivers' a real issue, and if so, is the above a reasonable avenue to take? - convert in-tree callers to use ide_in_device_list() instead, feeding it ata_device_blacklist[], and remove drive_blacklist[] from drivers/ide/ide-dma.c. Q4. What would you like to do for drive_whitelist[]? > Care to respin both patches? Before the questions are answered I cannot respin the earlier #2/3, but I can certainly respin #3/3. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Portable syscall inspection
Someone finally noticed that my program that uses ptrace only works on i386.. and, by the looks of it, there is no portable way to refer to the registers of a user_regs_struct when inspecting a system call. I will probably end up making a header file for each architecture that defines where in the user_regs_struct things like the syscall number, the return value and the first 3 parameters are.. has anyone done this already? or can otherwise save me a lot of time? Thanks, Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: b44: regression in 2.6.22 (resend)
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote: > > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution > > > Timer, but the high ping problem is still there. > > > > Hmm, that's mysterious. Wild guess is that highres exposes the hidden > > "feature" in a different way than rc2-mm1 does. > > I think the bug in 2.6.21/22-rc3 is a different one that the one in > 2.6.22-rc2-mm1, but that's also only a wild guess :) > > I'll explain this a bit: > In 2.6.21/22-rc3 is the same b44 driver that has been in the stock kernels for > some time. With this driver and High Resolution Timer turned on I get > problems using iperf. The problems are that the systems becomes really slow > and unresponsive. Michael Buesch thought this could be an IRQ storm which > sounds logical to me. This bug did never happen to me before I startet the > iperf test. Can you please apply http://www.tglx.de/projects/hrtimers/2.6.22-rc3/patch-2.6.22-rc3-hrt1.patch on top of rc3 and check, whether it has any effect on your problem. > The other issue happens only with 2.6.22-rc2-mm1 which includes the b44 ssb > spilt. It's independed wether High Resolution Timer is turned on or off I > always get very varying and high ping times. The iperf-test doesn't show the > problems from 2.6.21/22-rc3. Neither with nor without highres ? tglx Neither with nor without Gleixner ? Neither with nor without Buesch ? Neither with nor without Miller ? Neither with nor without Kyle ? Neither with nor without ? Neither with nor without would-like-to-spare time hackers ? Neither with nor without profile neurotic would-like-to-copyright owners ? ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] LZO de/compression support - take 6
On 5/28/07, Bret Towe <[EMAIL PROTECTED]> wrote:
On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is kernel port of LZO1X-1 compressor and LZO1X decompressor (safe
> version only).
>
> * Changes since 'take 5' (Full Changelog after this):
> - Added compressor and decomrpesssor as separate and hidden config
> options (default: n)
> - Cleanups: removed LZO_CHECK_MPOS_NON_DET macro
> - removed PTR* macros.
>
> * Benchmarks: (system: P4 3GHz, 1G RAM)
> (Using tester program from Daniel)
>
> Following compares this kernel port ('take 6') vs original miniLZO code:
>
> 'TinyLZO' refers to this kernel port.
>
> 1 run averages:
> 'Tiny LZO':
>Combined: 61.2223 usec
>Compression: 41.8412 usec
>Decompression: 19.3811 usec
> 'miniLZO':
>Combined: 66.0444 usec
>Compression: 46.6323 usec
>Decompression: 19.4121 usec
>
> Result:
> Overall: TinyLZO is 7.3% faster
> Compressor: TinyLZO is 10.2% faster
> Decompressor: TinyLZO is 0.15% faster
>
> TODO: test 'take 6' port on archs other than x86(_32)
>
> * Changelog vs. original LZO:
> 1) Used standard/kernel defined data types: (this eliminated _huge_
> #ifdef chunks)
> lzo_bytep -> unsigned char *
> lzo_uint -> size_t
> lzo_xint -> size_t
> lzo_uint32p -> u32 *
> lzo_uintptr_t -> unsigned long
> 2) Removed everything #ifdef'ed under COPY_DICT (this is not set for
> LZO1X, so removed corres. parts).
> 3) Removed code #ifdef'ed for LZO1Y, LZO1Z, other variants.
> 4) Reformatted the code to match general kernel style.
> 5) The only code change: (as suggested by Andrey)
> -#if defined(__LITTLE_ENDIAN)
> - m_pos = op - 1;
> - m_pos -= (*(const unsigned short *)ip) >> 2;
> -#else
> - m_pos = op - 1;
> - m_pos -= (ip[0] >> 2) + (ip[1] << 6);
> -#endif
>
> + m_pos = op - 1 - (cpu_to_le16(*(const u16 *)ip) >> 2);
>
> (Andrey suggested le16_to_cpu for above but I think it should be cpu_to_le16).
> *** Need testing on big endian machine ***
>
> Similarly:
> -#if defined(__LITTLE_ENDIAN)
> - m_pos -= (*(const unsigned short *)ip) >> 2;
> -#else
> - m_pos -= (ip[0] >> 2) + (ip[1] << 6);
> -#endif
>
> + m_pos -= cpu_to_le16(*(const u16 *)ip) >> 2;
>
> 6) Get rid of LZO_CHECK_MPOS_NON_DET macro and PTR* macros.
>
>
> I think it's now ready for mainline inclusion.
>
>
> include/linux/lzo1x.h| 66 +++
> lib/Kconfig |6 +
> lib/Makefile |2 +
> lib/lzo1x/Makefile |2 +
> lib/lzo1x/lzo1x_compress.c | 259
tested this on ppc and its still good
is there any reason to bother with a test on amd64?
if there is I might be able to get to it tonight
forgot to mention that it would make life easier if you would put the
version of the patch
in the .bz2 files you attach since you poping out new takes so quick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] LZO de/compression support - take 6
On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
Hi,
Attached is tester code used for testing.
(developed by Daniel Hazelton -- modified slightly to now use 'take 6'
version for 'TinyLZO')
Cheers,
Nitin
On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> (Using tester program from Daniel)
>
> Following compares this kernel port ('take 6') vs original miniLZO code:
>
> 'TinyLZO' refers to this kernel port.
>
> 1 run averages:
> 'Tiny LZO':
>Combined: 61.2223 usec
>Compression: 41.8412 usec
>Decompression: 19.3811 usec
> 'miniLZO':
>Combined: 66.0444 usec
>Compression: 46.6323 usec
>Decompression: 19.4121 usec
>
> Result:
> Overall: TinyLZO is 7.3% faster
> Compressor: TinyLZO is 10.2% faster
> Decompressor: TinyLZO is 0.15% faster
>
1 run averages:
'Tiny LZO':
Combined: 112.6642 usec
Compression: 56.3321 usec
Decompression: 56.3321 usec
'miniLZO':
Combined: 77.6642 usec
Compression: 56.3416 usec
Decompression: 21.3226 usec
now the interesting bit I thought was the following
[EMAIL PROTECTED]:/usr/src/lzo1x-test-4# ./fulltest
[test_lzo.c::compress (93)] run took 42 microseconds
[test_lzo.c::decompress (127)] run took 20 microseconds
[EMAIL PROTECTED]:/usr/src/lzo1x-test-4# ./tinytest
[test.c::compress (91)] run took 44 microseconds
[test.c::decompress (117)] BUG: lzo1x_decompress has failed ( t == -6 )
[test.c::main (149)] BUG: Decompression routine failure
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] LZO de/compression support - take 6
On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
Hi,
This is kernel port of LZO1X-1 compressor and LZO1X decompressor (safe
version only).
* Changes since 'take 5' (Full Changelog after this):
- Added compressor and decomrpesssor as separate and hidden config
options (default: n)
- Cleanups: removed LZO_CHECK_MPOS_NON_DET macro
- removed PTR* macros.
* Benchmarks: (system: P4 3GHz, 1G RAM)
(Using tester program from Daniel)
Following compares this kernel port ('take 6') vs original miniLZO code:
'TinyLZO' refers to this kernel port.
1 run averages:
'Tiny LZO':
Combined: 61.2223 usec
Compression: 41.8412 usec
Decompression: 19.3811 usec
'miniLZO':
Combined: 66.0444 usec
Compression: 46.6323 usec
Decompression: 19.4121 usec
Result:
Overall: TinyLZO is 7.3% faster
Compressor: TinyLZO is 10.2% faster
Decompressor: TinyLZO is 0.15% faster
TODO: test 'take 6' port on archs other than x86(_32)
* Changelog vs. original LZO:
1) Used standard/kernel defined data types: (this eliminated _huge_
#ifdef chunks)
lzo_bytep -> unsigned char *
lzo_uint -> size_t
lzo_xint -> size_t
lzo_uint32p -> u32 *
lzo_uintptr_t -> unsigned long
2) Removed everything #ifdef'ed under COPY_DICT (this is not set for
LZO1X, so removed corres. parts).
3) Removed code #ifdef'ed for LZO1Y, LZO1Z, other variants.
4) Reformatted the code to match general kernel style.
5) The only code change: (as suggested by Andrey)
-#if defined(__LITTLE_ENDIAN)
- m_pos = op - 1;
- m_pos -= (*(const unsigned short *)ip) >> 2;
-#else
- m_pos = op - 1;
- m_pos -= (ip[0] >> 2) + (ip[1] << 6);
-#endif
+ m_pos = op - 1 - (cpu_to_le16(*(const u16 *)ip) >> 2);
(Andrey suggested le16_to_cpu for above but I think it should be cpu_to_le16).
*** Need testing on big endian machine ***
Similarly:
-#if defined(__LITTLE_ENDIAN)
- m_pos -= (*(const unsigned short *)ip) >> 2;
-#else
- m_pos -= (ip[0] >> 2) + (ip[1] << 6);
-#endif
+ m_pos -= cpu_to_le16(*(const u16 *)ip) >> 2;
6) Get rid of LZO_CHECK_MPOS_NON_DET macro and PTR* macros.
I think it's now ready for mainline inclusion.
include/linux/lzo1x.h| 66 +++
lib/Kconfig |6 +
lib/Makefile |2 +
lib/lzo1x/Makefile |2 +
lib/lzo1x/lzo1x_compress.c | 259
tested this on ppc and its still good
is there any reason to bother with a test on amd64?
if there is I might be able to get to it tonight
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][EXPERIMENTAL] Make kernel threads nonfreezable by default
Hi. On Tue, 2007-05-29 at 00:51 +0200, Rafael J. Wysocki wrote: > > The copy_flags routine changes another process's flags - that's why > I > > was suggesting this. > > Yes, it does, but I'm dropping the clearing of PF_NOFREEZE from there, > not adding anything new. :-) Doh! Sorry :) Nigel signature.asc Description: This is a digitally signed message part
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
Hi. On Mon, 2007-05-28 at 14:03 +0100, Matthew Garrett wrote: > On Mon, May 28, 2007 at 02:55:07PM +0200, Pavel Machek wrote: > > > Well, PPC people are aware of this, and they think they can fix the > > drivers. We probably want to drop the freezer for suspend long-term, > > so. PPC machines use small subset of all the drivers, so it apparently > > is not big problem for them. > > I'm fairly certain that PPC uses USB. In any case, it's not limited to > PPC - APM has the same issue. Any driver that assumes processes will be > frozen during suspend to RAM is broken now, not the future. The converse is also true, though. Any process that assumes processes aren't frozen during suspend to RAM is also broken now, and will be while we allow the possibility of suspending to ram after writing a hibernation image. In short, drivers should be designed to work whether processes are frozen or not. Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: [2.6.21.1] resume doesn't run suspended kernel?
Hi. On Mon, 2007-05-28 at 19:57 +0200, Rafael J. Wysocki wrote: > On Monday, 28 May 2007 15:26, Pavel Machek wrote: > > Hi! > > > > > >That's clear, I'll have to use xen or kvm or similar which restores > > > >the system as suspended. Thanks for the clarification of the limitations. > > > > > > > Sorry, I wrote that late at night and quickly. I should have said > > > "design decision" rather than "limitation," For systems which don't do > > > multiple kernels it's not an issue. > > > > > > I certainly would not have made the same decision, but I didn't write > > > the code. It seems more robust to save everything than to try to > > > identify what has and hasn't changed in a modular kernel. > > > > We rely on atomic copy routine not moving inside the kernel. Yes, it > > would be possible to copy it to "known good" address and gain ability > > to resume different kernels. Actually it should not be _that_ hard. > > Yup. Don't we do something like this for the (ACPI-based) suspend to RAM > already? Yeah, I was thinking about this overnight too. It should be doable. In addition to what we already do, I think you'd want: - to copy the assembly to do the copying to a safe page; - to put the location of the cpu state that was saved in the image header so that it can be used after the data is copied back; - to copy the nosave data to a 'safe' page. What else? Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH]Multi-threaded Initcall with dependence support
On Mon, 28 May 2007 15:03:10 +0800 Yang Sheng wrote:
> Why we need this:
>
> It can speed up the calling of initcalls, especially useful for some embed
> device.
Can you give concrete example(s) of why we need this?
Any real configs/hardware where it helps and how much it helps.
General:
1/ Patch has 12 lines with trailing whitespace. Please chop those
off (always).
2/ Try to keep sources lines < 80 characters.
3/ Read & use Documentation/CodingStyle, Documentation/SubmittingPatches,
and Documentation/SubmitChecklist.
> Idea:
>
> 1. The initcall can indicate a executing sequence by using the a
> macro(initcall_depend()) in case of causing dependence problem in
> multi-threaded running. Multi dependences is also allowed.
> 2. Ensure the calling of initcalls in the same layer would be completed
> before
> the next layers' calling.
>
> Usage:
> You can indicate that initcall A must be run after initcall B by calling the
> macro in A's file:
>
> initcall_depend(A, B);
>
> Means initcall A must run after initcall B finish executing(A depends on B).
>
> Take notice of that if you declare A depends on B and C, you must put these
> together as (the sequences is not important):
>
> initcall_depend(A, B);
> initcall_depend(A, C);
>
> The detail of method:
>
> A new section called .initcall.depend was added to
> arch/xxx/kernel/vmlinux.lds.S to indicate the dependence relationship. A
> struct called initcall_depend_t stored the relationship between A and B, and
> was stored in section .initcall.depend.
>
> Because all the dependence of A are put together, and the sequences of
> initcall_depend_t was decided in linker order as initcall itself did. When A
> is going to run, we can check if A would depend on others by checking the
> point indicate the current item in dependence table. If the field "call" of
> initcall_depend_t point to A, we know that A is depend on something and get
> the prev_addr of the struct to find what it depends on. The field "prev_addr"
>
> point to somewhere in .initcall.init section to indicate the address(also the
> order) of depended initcall, so it can be used to find out whether other
> threads complete executing of the depended initcall. If the current point of
> the thread executing is smaller than prev_addr(it means some thread not
> completed executing, not only this thread), we'll wait, otherwise we can
> continue to check next thread. If all the thread is ok, we will run the
> initcall and go to the next one.
>
> This method is not very precision(for we may have to wait even when the
> initcall was completed but not all the other pass it), but easy to implement.
>
> I provide two method to get the dependence relationship, the following code
> contains the one which is more flexibly but less efficiency.
>
> The downside of this patch is every driver must explictly indicate its
> dependence, please tell if this is acceptable. Any suggestions and comments
> are welcome.
>
> Thanks.
>
>
>
> arch/x86_64/kernel/vmlinux.lds.S |6 +
> include/linux/init.h | 16 +++
> init/main.c | 257 +++--
> 3 files changed, 237 insertions(+), 42 deletions(-)
>
> diff --git a/arch/x86_64/kernel/vmlinux.lds.S
> b/arch/x86_64/kernel/vmlinux.lds.S
> index dbccfda..355c8b6 100644
> --- a/arch/x86_64/kernel/vmlinux.lds.S
> +++ b/arch/x86_64/kernel/vmlinux.lds.S
> @@ -167,6 +167,12 @@ SECTIONS
> INITCALLS
>}
>__initcall_end = .;
> + . = ALIGN(16);
> + __initcall_depend_start = .;
> + .initcall.depend : AT(ADDR(.initcall.depend) - LOAD_OFFSET) {
> + *(.initcall.depend)
> + }
> + __initcall_depend_end = .;
>__con_initcall_start = .;
>.con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
> *(.con_initcall.init)
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 56ec4c6..68134d7 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -73,7 +73,17 @@
> /*
> * Used for initialization calls..
> */
> +
> typedef int (*initcall_t)(void);
> +
> +typedef struct {
> + initcall_t call;
> + union {
> + initcall_t func;
> + initcall_t* addr;
> + } prev;
> +} initcall_depend_t;
Don't add typedefs as shortcuts for struct names.
> +
> typedef void (*exitcall_t)(void);
>
> extern initcall_t __con_initcall_start[], __con_initcall_end[];
> @@ -108,6 +118,12 @@ void prepare_namespace(void);
> static initcall_t __initcall_##fn##id __attribute_used__ \
> __attribute__((__section__(".initcall" level ".init"))) = fn
>
> +#define initcall_depend(fn, req) \
> + static initcall_depend_t __dependency_##fn_after_##req \
> + __attribute_used__ __attribute__((__section__(".initcall.depend"))) = {
> \
> + .call = fn, \
> + .prev.func = req }
> +
> /*
> * A "pure" initcall has no dependencies on anything else, and purely
> * initializes
Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default
On Monday, 28 May 2007 23:26, Nigel Cunningham wrote:
> Hi.
>
> On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
> > On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
> > > Hello!
> > >
> > > In reply to your more recent message, I had looked but not tried, so
> > > didn't feel in a position to reply yet.
> > >
> > > On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
> > > > 63 files changed, 78 insertions(+), 138 deletions(-)
> > >
> > > Well, that looks good, for a start :)
> > >
> > > > Index: linux-2.6.22-rc3/kernel/exit.c
> > > > ===
> > > > --- linux-2.6.22-rc3.orig/kernel/exit.c
> > > > +++ linux-2.6.22-rc3/kernel/exit.c
> > > > @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
> > > > * they would be locked into memory.
> > > > */
> > > > exit_mm(current);
> > > > + /*
> > > > +* We don't want to have TIF_FREEZE set if the system-wide
> > > > hibernation
> > > > +* or suspend transision begins right now.
> > > > +*/
> > > > + current->flags |= PF_NOFREEZE;
> > >
> > > s/transision/transition
> >
> > Thanks, will fix.
> >
> > > > set_special_pids(1, 1);
> > > > proc_clear_tty(current);
> > > > Index: linux-2.6.22-rc3/include/linux/freezer.h
> > > > ===
> > > > --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> > > > +++ linux-2.6.22-rc3/include/linux/freezer.h
> > > > @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
> > > > return !!(p->flags & PF_FREEZER_SKIP);
> > > > }
> > > >
> > > > +/*
> > > > + * Tell the freezer that the current task should be frozen by it
> > > > + */
> > > > +static inline void set_freezable(void)
> > > > +{
> > > > + current->flags &= ~PF_NOFREEZE;
> > > > +}
> > > > +
> > >
> > > Given the clearing of the flag above, should we just have a
> > > set_unfreezeable here that's used above (and potentially elsewhere)...
> > > (reads more)... or more generic set_[un]freezeable(task_struct *p)
> > > routines that could also be used in copy_flags below?
> >
> > Yes, I can introduce set_unfreezeable(), although that would be used in
> > a couple of places only.
> >
> > I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
> > since only current is allowed to set/unset its flags.
>
> The copy_flags routine changes another process's flags - that's why I
> was suggesting this.
Yes, it does, but I'm dropping the clearing of PF_NOFREEZE from there,
not adding anything new. :-)
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: stuff ready to be deleted?
On Mon, 28 May 2007, Robert P. J. Day wrote: > On Mon, 28 May 2007, Jan Engelhardt wrote: > > > > > On May 28 2007 16:15, Robert P. J. Day wrote: > > >removing dead content from the tree: > > > > > >http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List > > > > > >currently, the list contains the items: > > > > > >* 4 Traffic policing > > > > CONFIG_NET_SCHED? CONFIG_NET_ACT_POLICE? Neither seems > > marked as deprecated/obsoleted in Kconfig. > > the "traffic policing" entry in that list refers specifically to the > config option "CLS_NET_POLICE" in net/sched/Kconfig: > > config NET_CLS_POLICE > bool "Traffic Policing (obsolete)" > depends on NET_CLS_ACT!=y > select NET_ESTIMATOR > ---help--- > Say Y here if you want to do traffic policing, i.e. strict > bandwidth limiting. This option is obsoleted by the traffic > policer implemented as action, it stays here for compatibility > reasons. > > so ... does "obsolete" really mean "obsolete"? whoops, the URL i gave above is only for the main page, not for the specific "stuff to be removed" list here: http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7 RESEND] cxgb3 - Update FW to 4.1
[EMAIL PROTECTED] wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Bump FW version to 4.1. Modify chip tuning in consequence. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/regs.h|4 drivers/net/cxgb3/t3_hw.c | 40 ++-- drivers/net/cxgb3/version.h |2 +- 3 files changed, 27 insertions(+), 19 deletions(-) You think requiring a FIRMWARE UPGRADE is something that should be done in the middle of a kernel bugfix series? What Q/A planet are you from? This is a completely ridiculous burden you are placing on the individual user. A good driver knows that firmware NOT SHIPPED WITH THE KERNEL does not necessarily move in lock-step with the kernel driver. You are welcome to GPL your firmware and ship it of course 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 3/7] cxgb3 - Fix direct XAUI support
[EMAIL PROTECTED] wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Check all lanes for link status on direct XAUI cards. Don't assume that direct XAUI always uses XGMAC 1. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/ael1002.c | 10 -- drivers/net/cxgb3/regs.h|2 ++ 2 files changed, 10 insertions(+), 2 deletions(-) ACK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/7] cxgb3 - fix netpoll hanlder
[EMAIL PROTECTED] wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
Fix netpoll handler to work with line interrupt, msi and msi-x.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c | 12 +---
drivers/net/cxgb3/sge.c|1 -
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 67b4b21..e0ef724 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2076,10 +2076,16 @@ static void vlan_rx_kill_vid(struct net_
static void cxgb_netpoll(struct net_device *dev)
{
struct adapter *adapter = dev->priv;
- struct sge_qset *qs = dev2qset(dev);
+ struct port_info *pi = netdev_priv(dev);
+ int qidx;
- t3_intr_handler(adapter, qs->rspq.polling) (adapter->pdev->irq,
- adapter);
+ for (qidx = pi->first_qset; qidx < pi->first_qset + pi->nqsets; qidx++)
{
+ struct sge_qset *qs = >sge.qs[qidx];
+
+ t3_intr_handler(adapter, qs->rspq.polling) (0,
+ (adapter->flags & USING_MSIX) ?
+ (void *)qs : (void *)adapter);
Remove needless casts to void*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/7] cxgb3 - Fix SGE page management
[EMAIL PROTECTED] wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Streamline page management on RX. Fix dma mappings. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> NAK #1: "streamline" is not a bug-fixes-only change, which is the only type of change appropriate for 2.6.22-rc. NAK #2: You should use the page_address(page) accessor rather than creating a struct member in the same struct as your page, solely to contain the virtual address. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Cliffe wrote: > The following would be used in conjunction with a pathname based > confinement to try to provide some assurances about what a path refers > to. > > "/etc/shadow" is a name to a sensitive resource. There is no guarantee > that there are not other ways to access this resource. For example a > link "/etc/shadowlink" or a rename to "/etc/shadownewname" > > Pathname based security has various advantages (such as the ability to > have more readable and centralised policies by describing resources in > terms of their pathnames) but the above is clearly a problem (if > confidentiality or integrity of a specific resource is important). > > Could we find a way to make paths a more reliable mechanism by > labeling the file data with a simple description of names it is > allowed to be accessed with? > > If we want "/etc/shadow" to be the only way to access the shadow file > we could label the data with "/etc/shadow". Any attempts to access > this data using a renamed file or link would be denied (attempts to > link or rename could also be denied). Eloquently put. AppArmor actually does something similar to this, by mediating all of the ways that you can make an alias to a file. These are: * Symbolic links: these actually don't work for making aliases with respect to LSM-based security systems such as AppArmor, SELinux, and TOMOYO Linux, because the symbolic link is resolved before the access request is presented to the LSM hooks. So if you create the symbolic link /tmp/harmless -> /etc/shadow and then the confined victim tries to access /tmp/harmless, what the LSM sees is an attempt to access /etc/shadow. * Hard links: AppArmor explicitly mediates permission to make a hard link to a file. To be able to make a hard link /tmp/harmless -> /etc/shadow you have to have explicit permission to do so, or the attempt to make the link is blocked. This mediation is kept relatively simple by the fact that you can only hard link to files, and not to directories. * Multiple mounts: Linux lets you mount the same file system multiple times at multiple mount points, so the same file could appear at two different places. AppArmor has very coarse mediation here, and simply prohibits all calls to mount() without special permission. So only highly privileged processes can create such an alias. * Name spaces: Linux name spaces present a similar issue, and AppArmor's coarse blocking of mount() serves the same function; only highly privileged processes are permitted to create name spaces. > We could label a document with "/home/me/documents/*". Then the > document could be linked or renamed within that specified directory. We are thinking about something kind of like this for finer-grained mediation of mount(). Currently it is all-or-nothing; we either totally block the ability to create aliases with multiple mount points or name spaces, or we totally trust the process with permission to do what it likes with multiple mount point and name space aliases. What we want is a more nuanced mediation of mount point and name space manipulation, so that you can write a spec that says "/tmp/* can be aliased any way you like, but /etc/shadow cannot be aliased at all" or something like that. However, not much work has been done on this, because at the moment the AppArmor team is concentrating on making the code for current functionality acceptable for upstreaming. > Obvious problems with this solution: > * it seems hard to determine what the label should be set to (setting > it to "*" would be tempting and completely negate the whole thing, > while setting it to the current filename would often be too restrictive). This is equivalent to the question of what kind of access to grant to the data. I don't see it as really difficult. What is harder is that the specification has to specify what you can alias, and where it can appear, and dealing with the two factors tends to make one's head hurt. I am reminded of the pithy quote "Noalias must go. This is not negotiable" -- Dennis Ritchie, referring to a proposed 'noalias' type qualifier in ANSI C http://www.lysator.liu.se/c/dmr-on-noalias.html Mediating permission to make aliases is complicated :( > * when files are created these labels need to be created, and they may > need to be changed. .. if you use the approach of labeling the files :) In fact this problem is general: label-based security has a hard time dealing with new files in general, not just with respect to permission to create aliases. The security policy for a newly created file is determined by the label on the file, and so labeling new files is critical. SELinux uses a variety of smart heuristics to decide the label of a new file: * the label of the parent directory * the label of the creating process * the domain for the creating process can do conditional things based on the
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On Mon, 28 May 2007, Pavel Machek wrote: > > The theoretical answer is that it behaves the way we want. The kernel > > thread does selective resumes in response to device requests. If such > > a request comes in while the system is asleep it will awaken the > > system; so it's only logical that a request coming in while the system > > is in the process of going to sleep should abort the suspend. > > I'd say that it shows ppc being broken. User wanted to suspend the > system, and now unrelated task did lsusb... and system will not sleep. > > AFAICT it is DoS issue -- if one of your users keeps doing lsusb, root > will not be able to suspend the system. This is a matter of one's philosophy. In suspend-to-RAM, should tasks be frozen or should I/O queues be frozen? With the USB subsystem I have followed the approach taken by the PM core, which is that tasks are frozen. But one can -- and Linus has on at least one occasion -- make a good case that tasks should be left running while only I/O is frozen. This would require the subsystem to distinguish between a selective device suspend and a system-wide suspend-to-RAM, so that selective resume could be enabled on demand in one case but not the other. It's quite doable in principle -- it's just not the technique I used. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: stuff ready to be deleted?
Bill Davidsen wrote: OSS [is] maintained by an independent commercial company (4Front) so maintenance isn't an issue, False. OSS drivers have been largely maintainerless for years. 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: stuff ready to be deleted?
On Mon, 28 May 2007, Jan Engelhardt wrote: > > On May 28 2007 16:15, Robert P. J. Day wrote: > >removing dead content from the tree: > > > >http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List > > > >currently, the list contains the items: > > > >* 4 Traffic policing > > CONFIG_NET_SCHED? CONFIG_NET_ACT_POLICE? Neither seems > marked as deprecated/obsoleted in Kconfig. the "traffic policing" entry in that list refers specifically to the config option "CLS_NET_POLICE" in net/sched/Kconfig: config NET_CLS_POLICE bool "Traffic Policing (obsolete)" depends on NET_CLS_ACT!=y select NET_ESTIMATOR ---help--- Say Y here if you want to do traffic policing, i.e. strict bandwidth limiting. This option is obsoleted by the traffic policer implemented as action, it stays here for compatibility reasons. so ... does "obsolete" really mean "obsolete"? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stuff ready to be deleted?
Oliver Pinter wrote: + open sound system Why? OSS supports some hardware ALSA doesn't, it's maintained by an independent commercial company (4Front) so maintenance isn't an issue, and it's portable to many other operating systems. Functionality and low TCO, what could be better? New Linux code, including x86_64 3D drivers, was released in April, so there's no lack of new features and activity. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: V4L2 - Leadtek Winfast PVR 2000 XP makes partial kernel freeze
Kernel very often freezes when I watch TV on my card TV Leadtek Winfast PVR 2000 XP. When I watch TV in KdeTV, I got message like "problem with v4l2" and then no picture, only sound. (Some tv applications dont run at all). After that I can normally work witch computer but I can't run ps aux, which freezes and turn off computer. Kernel version: 2.6.20.x (kernel in ubuntu 2.6.20-15 is ok, but 2.6.20-16 is not), 2.6.21.1(my compilation), 2.6.21.2(my compilation) This reports are from 2.6.20-15-generic: cat /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping: 2 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dno wext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy bogomips: 2011.54 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping: 2 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dno wext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy bogomips: 2011.54 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc cat /proc/modules: snd_rtctimer 5216 1 - Live 0x88c06000 rfcomm 45352 0 - Live 0x88bf9000 l2cap 28160 5 rfcomm, Live 0x88bf1000 bluetooth 62340 4 rfcomm,l2cap, Live 0x88be ppdev 11272 0 - Live 0x88bdc000 capifs 7824 1 - Live 0x88bd9000 powernow_k8 16480 1 - Live 0x88bd3000 cpufreq_userspace 6176 0 - Live 0x88bd cpufreq_stats 8416 0 - Live 0x88bcc000 cpufreq_powersave 3072 0 - Live 0x8807e000 cpufreq_ondemand 10640 1 - Live 0x88bc8000 freq_table 6336 3 powernow_k8,cpufreq_stats,cpufreq_ondemand, Live 0x88bc5000 cpufreq_conservative 9736 0 - Live 0x88bc1000 tc1100_wmi 9224 0 - Live 0x88bbd000 sony_acpi 7064 0 - Live 0x88bba000 pcc_acpi 15616 0 - Live 0x88bb5000 dev_acpi 17028 0 - Live 0x88baf000 video 19080 0 - Live 0x88ba9000 sbs 17856 0 - Live 0x88ba3000 i2c_ec 6784 1 sbs, Live 0x88ba dock 11992 0 - Live 0x88b9c000 container 6144 0 - Live 0x88b99000 button 10016 0 - Live 0x88b95000 battery 12040 0 - Live 0x88b91000 asus_acpi 19756 0 - Live 0x88b8b000 backlight 8448 1 asus_acpi, Live 0x88b87000 ac 6920 0 - Live 0x88b84000 nls_utf8 3456 1 - Live 0x88079000 ntfs 101960 1 - Live 0x88b6a000 reiserfs 248576 1 - Live 0x88b2c000 ext2 72464 1 - Live 0x88b19000 mbcache 11400 1 ext2, Live 0x88b15000 it87 24336 0 - Live 0x88b0e000 hwmon_vid 4864 1 it87, Live 0x88b0b000 i2c_isa 7680 1 it87, Live 0x88b08000 eeprom 9744 0 - Live 0x88b04000 lp 15048 0 - Live 0x88aff000 fuse 51888 0 - Live 0x88af1000 snd_intel8x0 38952 1 - Live 0x88ae6000 snd_ac97_codec 117720 1 snd_intel8x0, Live 0x88ac8000 ac97_bus 3968 1 snd_ac97_codec, Live 0x88071000 snd_pcm_oss 49536 0 - Live 0x88aba000 snd_mixer_oss 19840 1 snd_pcm_oss, Live 0x88ab4000 snd_pcm 92808 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss, Live 0x88a9c000 tuner 67368 0 - Live 0x88a8a000 snd_seq_dummy 5380 0 - Live 0x88a87000 snd_seq_oss 36608 0 - Live 0x88a7d000 snd_seq_midi 11008 0 - Live 0x88a79000 snd_rawmidi 29696 1 snd_seq_midi, Live 0x88a7 snd_seq_midi_event 9856 2 snd_seq_oss,snd_seq_midi, Live 0x88a6c000 snd_seq 61856 7 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event, Live 0x88a5b000 snd_timer 26632 3 snd_rtctimer,snd_pcm,snd_seq, Live 0x88a53000 snd_seq_device 10260 5
Re: NOHZ: local_softirq_pending 08
On Tuesday 29 May 2007 02:34:22 Rafał Bilski wrote: > Hi! > > A lot of "NOHZ: local_softirq_pending 08" messages (about 100) and > then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 > changelogs but I don't see anything about this message. > What does it mean? > > Is "08" IRQ number? > 8: 2XT-PIC-XTrtc > > Please CC me. Does this patch [ http://lkml.org/lkml/2007/5/22/35 ] helps you fix it ? Regards Ananitya -- Out of many thousands, one may endeavor for perfection, and of those who have achieved perfection, hardly one knows Me in truth. -- Gita Sutra Of Mysticism - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
Mauro Carvalho Chehab a écrit : As Luca pointed, if we add conversion for one driver, we should add for the rest. Instead, it would be better if Jiri sends the decoding and the rescaling stuff as a patch to v4l2-apps/lib, starting the API decoding library. Once we have a library, we can ask the userspace developers to use it for the formats not recognized by their userspace apps. I think it would be better to evaluate existing solutions (eg. libpw). Agreed. Volunteers? Hi Mauro and Markus, Just to summ up what I understood we need: What do we need in userspace, only for v4l (dvb is not concerned): - colorspace translations - filters that be done in hardware if the selected hardware can, otherwise software plugin - decompression algorithm like stk11xx or usbvision (the decompression algorithm is in kernelspace since it is of linear complexity but shall be moved to userspace) Using pwlib will not mean that application developers will use pwlib to decode v4l driver outputs. C bindings are much more popular than C++ bindings and do not prevent object oriented design. Application developers implement their own codecs. As an example, every application do deinterlacing internally or not... Application developers will probably not use pwlib v4l extensions because they will prefer to write adapted codecs for their framework. Much more important for me is to see the actual specification of the needed v4l extensions points, with advice/participation of application/codec developers. Thierry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] pata_sis: FIFO whack
Alan Cox wrote: If you are using a SiS controller and the BIOS didn't set it up then the FIFO may be left active when we try and set up the CD. Not convinced this matters but I'd prefer to be safe Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc2-mm1/drivers/ata/pata_sis.c linux-2.6.22-rc2-mm1/drivers/ata/pata_sis.c --- linux.vanilla-2.6.22-rc2-mm1/drivers/ata/pata_sis.c 2007-05-25 17:39:06.0 +0100 +++ linux-2.6.22-rc2-mm1/drivers/ata/pata_sis.c 2007-05-25 18:22:21.0 +0100 @@ -149,6 +149,9 @@ if (!pci_test_config_bits(pdev, _enable_bits[ap->port_no])) return -ENOENT; + /* Clear the FIFO settings. We can't enable the FIFO until + we know we are poking at a disk */ + pci_write_config_byte(pdev, 0x4B, 0); return ata_std_prereset(ap, deadline); Should I queue this into #upstream (2.6.23) or #upstream-fixes (2.6.22-rc) branch? I lean towards #upstream since it is so late in the 2.6.22-rc cycle, because of your comment "Not convinced this matters". 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] ARM/ARM26: Enable arbitary speed tty ioctls and split input/output speed
On Mon, May 28, 2007 at 02:56:32PM -0700, Andrew Morton wrote: > On Mon, 28 May 2007 20:36:58 +0100 Russell King <[EMAIL PROTECTED]> wrote: > > > On Wed, May 23, 2007 at 05:27:39PM +0100, Alan Cox wrote: > > > Add the ioctls and values needed for this to the ARM26/ARM32 ports. The > > > actual code has been in the base kernel for a while and automatically > > > turns on when a port sets the required defines. > > > > Did you forget to provide a termios2 structure for ARM? Hope you > > remembered for the other arches: > > > > drivers/char/tty_ioctl.c: In function `set_termios': > > drivers/char/tty_ioctl.c:429: error: invalid application of `sizeof' to > > incomplete type `termios2' > > drivers/char/tty_ioctl.c: In function `n_tty_ioctl': > > drivers/char/tty_ioctl.c:732: error: invalid application of `sizeof' to > > incomplete type `termios2' > > > > Will copy the i386 version into ARM's termbits.h > > > > I think Alan's per-arch patch was dependent upon an earlier patch. He > fooled everyone by sending them out in random order, without sequence > nnumbers and without telling anyone the dependencies. And the add-termios2 > patch was a single megapatch whereas the enablement patches were a per-arch > sprinkle. > > > Here's tha arm bit of > lots-of-architectures-enable-arbitary-speed-tty-support.patch: I hope that isn't because it's wrong. It's "termios2" not "termios_2". > Or you can just drop this patch and I'll resend it once > lots-of-architectures-enable-arbitary-speed-tty-support.patch is merged up. I think I'd prefer to commit my own version copied from x86, which at least passes a build test. Doing that now. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ARM/ARM26: Enable arbitary speed tty ioctls and split input/output speed
On Mon, 28 May 2007 20:36:58 +0100 Russell King <[EMAIL PROTECTED]> wrote:
> On Wed, May 23, 2007 at 05:27:39PM +0100, Alan Cox wrote:
> > Add the ioctls and values needed for this to the ARM26/ARM32 ports. The
> > actual code has been in the base kernel for a while and automatically
> > turns on when a port sets the required defines.
>
> Did you forget to provide a termios2 structure for ARM? Hope you
> remembered for the other arches:
>
> drivers/char/tty_ioctl.c: In function `set_termios':
> drivers/char/tty_ioctl.c:429: error: invalid application of `sizeof' to
> incomplete type `termios2'
> drivers/char/tty_ioctl.c: In function `n_tty_ioctl':
> drivers/char/tty_ioctl.c:732: error: invalid application of `sizeof' to
> incomplete type `termios2'
>
> Will copy the i386 version into ARM's termbits.h
>
I think Alan's per-arch patch was dependent upon an earlier patch. He
fooled everyone by sending them out in random order, without sequence
nnumbers and without telling anyone the dependencies. And the add-termios2
patch was a single megapatch whereas the enablement patches were a per-arch
sprinkle.
Here's tha arm bit of
lots-of-architectures-enable-arbitary-speed-tty-support.patch:
diff -puN
include/asm-arm/termbits.h~lots-of-architectures-enable-arbitary-speed-tty-support
include/asm-arm/termbits.h
---
a/include/asm-arm/termbits.h~lots-of-architectures-enable-arbitary-speed-tty-support
+++ a/include/asm-arm/termbits.h
@@ -15,6 +15,17 @@ struct termios {
cc_t c_cc[NCCS];/* control characters */
};
+struct termios_2 {
+ tcflag_t c_iflag; /* input mode flags */
+ tcflag_t c_oflag; /* output mode flags */
+ tcflag_t c_cflag; /* control mode flags */
+ tcflag_t c_lflag; /* local mode flags */
+ cc_t c_line;/* line discipline */
+ cc_t c_cc[NCCS];/* control characters */
+ speed_t c_ispeed; /* input speed */
+ speed_t c_ospeed; /* output speed */
+};
+
struct ktermios {
tcflag_t c_iflag; /* input mode flags */
tcflag_t c_oflag; /* output mode flags */
Or you can just drop this patch and I'll resend it once
lots-of-architectures-enable-arbitary-speed-tty-support.patch is merged 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: Linux v2.6.22-rc3
Jeff Garzik wrote: Several people have reported LITE-ON LTR-48246S detection failed because SETXFER fails. It seems the device raises IRQ too early after SETXFER. This is controller independent. The same problem has been reported for different controllers. So, now we have pata_via where the controller raises IRQ before it's ready after SETXFER and a device which does similar thing. This patch makes libata always execute SETXFER via polling. As this only happens during EH, performance impact is nil. Setting ATA_TFLAG_POLLING is also moved from issue hot path to ata_dev_set_xfermode() - the only place where SETXFER can be issued. Note that ATA_TFLAG_POLLING applies only to drivers which implement SFF TF interface and use libata HSM. More advanced controllers ignore the flag. This doesn't matter for this fix as SFF TF controllers are the problematic ones. Not only kills two birds with a single store, but will avoid having to re-solve the problem at sometime in the future. That's good software! -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: What causes iowait other than waiting for i/o?
On 28/05/07, Bill Davidsen <[EMAIL PROTECTED]> wrote: I recently noted that my system was spending a lot of time in i/o wait when doing some tasks which I thought didn't involve i/o, as noted by the lack of disk light activity most of the time. I thought of network, certainly the NIC had no activity for this job. So I set up a little loop to capture all disk i/o and network activity (including loopback). That was no obvious help, and the program doesn't use pipes. At this point I'm really curious, does someone have a good clue? Note: I don't think this is a bug or performance issue, unless the kernel is doing something and charging time to iowait instead of system I don't see anything to fix, but I would like to understand. Nothing /should/ cause time to be attributed to i/o wait other than waiting for i/o. But the accounting isn't completely accurate. When the kernel records what the has happen (governed by when the timer interrupt triggers as far as I remember), many different processes may have run and done may different things, but only what the last one did is recorded. So if you are unlucky you may have the system doing all sorts of activities, but only recording i/o wait if the last process to run before the kernel looked was doing i/o wait... The numbers are not exactely accurate... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: b44: regression in 2.6.22 (resend)
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote: > > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution > > > Timer, but the high ping problem is still there. > > > > Hmm, that's mysterious. Wild guess is that highres exposes the hidden > > "feature" in a different way than rc2-mm1 does. > > I think the bug in 2.6.21/22-rc3 is a different one that the one in > 2.6.22-rc2-mm1, but that's also only a wild guess :) > > I'll explain this a bit: > In 2.6.21/22-rc3 is the same b44 driver that has been in the stock kernels > for > some time. With this driver and High Resolution Timer turned on I get > problems using iperf. The problems are that the systems becomes really slow > and unresponsive. Michael Buesch thought this could be an IRQ storm which > sounds logical to me. This bug did never happen to me before I startet the > iperf test. Can you please apply http://www.tglx.de/projects/hrtimers/2.6.22-rc3/patch-2.6.22-rc3-hrt1.patch on top of rc3 and check, whether it has any effect on your problem. > The other issue happens only with 2.6.22-rc2-mm1 which includes the b44 ssb > spilt. It's independed wether High Resolution Timer is turned on or off I > always get very varying and high ping times. The iperf-test doesn't show the > problems from 2.6.21/22-rc3. Neither with nor without highres ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
What causes iowait other than waiting for i/o?
I recently noted that my system was spending a lot of time in i/o wait when doing some tasks which I thought didn't involve i/o, as noted by the lack of disk light activity most of the time. I thought of network, certainly the NIC had no activity for this job. So I set up a little loop to capture all disk i/o and network activity (including loopback). That was no obvious help, and the program doesn't use pipes. At this point I'm really curious, does someone have a good clue? Note: I don't think this is a bug or performance issue, unless the kernel is doing something and charging time to iowait instead of system I don't see anything to fix, but I would like to understand. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: stuff ready to be deleted?
On May 28 2007 16:15, Robert P. J. Day wrote: >removing dead content from the tree: > >http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List > >currently, the list contains the items: > >* 4 Traffic policing CONFIG_NET_SCHED? CONFIG_NET_ACT_POLICE? Neither seems marked as deprecated/obsoleted in Kconfig. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][EXPERIMENTAL] Make kernel threads nonfreezable by default
Hi.
On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
> > Hello!
> >
> > In reply to your more recent message, I had looked but not tried, so
> > didn't feel in a position to reply yet.
> >
> > On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
> > > 63 files changed, 78 insertions(+), 138 deletions(-)
> >
> > Well, that looks good, for a start :)
> >
> > > Index: linux-2.6.22-rc3/kernel/exit.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/kernel/exit.c
> > > +++ linux-2.6.22-rc3/kernel/exit.c
> > > @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
> > >* they would be locked into memory.
> > >*/
> > > exit_mm(current);
> > > + /*
> > > + * We don't want to have TIF_FREEZE set if the system-wide hibernation
> > > + * or suspend transision begins right now.
> > > + */
> > > + current->flags |= PF_NOFREEZE;
> >
> > s/transision/transition
>
> Thanks, will fix.
>
> > > set_special_pids(1, 1);
> > > proc_clear_tty(current);
> > > Index: linux-2.6.22-rc3/include/linux/freezer.h
> > > ===
> > > --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> > > +++ linux-2.6.22-rc3/include/linux/freezer.h
> > > @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
> > > return !!(p->flags & PF_FREEZER_SKIP);
> > > }
> > >
> > > +/*
> > > + * Tell the freezer that the current task should be frozen by it
> > > + */
> > > +static inline void set_freezable(void)
> > > +{
> > > + current->flags &= ~PF_NOFREEZE;
> > > +}
> > > +
> >
> > Given the clearing of the flag above, should we just have a
> > set_unfreezeable here that's used above (and potentially elsewhere)...
> > (reads more)... or more generic set_[un]freezeable(task_struct *p)
> > routines that could also be used in copy_flags below?
>
> Yes, I can introduce set_unfreezeable(), although that would be used in
> a couple of places only.
>
> I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
> since only current is allowed to set/unset its flags.
The copy_flags routine changes another process's flags - that's why I
was suggesting this.
> > > #else
> > > static inline int frozen(struct task_struct *p) { return 0; }
> > > static inline int freezing(struct task_struct *p) { return 0; }
> > > @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) {
> > > static inline void freezer_do_not_count(void) {}
> > > static inline void freezer_count(void) {}
> > > static inline int freezer_should_skip(struct task_struct *p) { return 0;
> > > }
> > > +static inline void set_freezable_current(void) {}
>
> Ah, this is a mistake (wrong name).
>
> > > #endif
> > >
> > > #endif /* LINUX_FREEZER_H */
> > > Index: linux-2.6.22-rc3/kernel/fork.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/kernel/fork.c
> > > +++ linux-2.6.22-rc3/kernel/fork.c
> > > @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
> > > {
> > > unsigned long new_flags = p->flags;
> > >
> > > - new_flags &= ~(PF_SUPERPRIV | PF_NOFREEZE);
> > > + new_flags &= ~PF_SUPERPRIV;
> > > new_flags |= PF_FORKNOEXEC;
> > > if (!(clone_flags & CLONE_PTRACE))
> > > p->ptrace = 0;
> > > Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
> > > +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > > @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)
> > >
> > > for ( ; ; ) {
> > > time_remaining = schedule_timeout_interruptible(time_remaining);
> > > - try_to_freeze();
> > > if (time_after(jiffies,
> > > prev_balance_time+balanced_irq_interval)) {
> > > preempt_disable();
> >
> > I'm the one who is confused, aren't I? If I'm reading this right,
> > io_apic used to be frozen. After this patch, it will not be frozen. If
> > that's the intended behaviour, shouldn't this be two patches - one to
> > make kernel threads unfreezeable by default, and one to make threads
> > that were formerly freezeable unfreezeable?
>
> Yes, I think you're right. I tend to try to make too many changes in one
> shot. :-)
>
> >
> > [...]
> >
> > > Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > > ===
> > > --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
> > > +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > > @@ -140,22 +140,6 @@ should be sent to the mailing list avail
> > > website, and not to the Linux Kernel Mailing List. We are working
> > > toward merging suspend2 into the mainline kernel.
> > >
> > > -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
Re: stuff ready to be deleted?
On 28/05/07, John Anthony Kazos Jr. <[EMAIL PROTECTED]> wrote: > > i'm trying to keep track of kernel janitor projects that involve > > removing dead content from the tree: > > > > http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List > > > > currently, the list contains the items: > > > > * 1 Legacy power management > > * 2 PCMCIA IOCTL support > > * 3 Traffic shaper > > * 4 Traffic policing > > * 5 Userspace queueing via NETLINK > > * 6 ebt: ulog support > > * 7 MOXA SmartIO support > > * 8 Old I2O ioctls > > * 9 Stallion drivers > > * 10 SDL RISCom/8 support > > * 11 Macintosh M68K support > > * 12 Commodore A2232 serial support > > * 13 CONFIG_FORCED_INLINING > > * 14 kernel_thread() > > > > which of the above are legitimate candidates for removal? which are > > already underway in someone's local tree? anything else that can > > be added? etc, etc. > > > > Take a look at Documentation/feature-removal-schedule.txt > Some of that stuff is already listed there along with who is in charge > of removing it and when. Let's not get in that catfight again. That file has been demonstrated to be half too premature and half completely obsolete. He's asking for which things should he start generating and sending patches and expect them to not be ignored or angrily shot down. feature-removal-schedule.txt does not provide this information, again as has been demonstrated. Of course, it would be great if it were accurate and -did- provide that information. Well, at least that file does give him a clue as to who to talk to about removal of some of the items on the list. It may not be as up-to-date as it ought to be, but it's still a source of information/contact info. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: stuff ready to be deleted?
Robert P. J. Day napsal(a): > i'm trying to keep track of kernel janitor projects that involve > removing dead content from the tree: > > http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List > > currently, the list contains the items: [...] > * 7 MOXA SmartIO support already scheduled with the MXSER name. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: stuff ready to be deleted?
> > i'm trying to keep track of kernel janitor projects that involve > > removing dead content from the tree: > > > > http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List > > > > currently, the list contains the items: > > > > * 1 Legacy power management > > * 2 PCMCIA IOCTL support > > * 3 Traffic shaper > > * 4 Traffic policing > > * 5 Userspace queueing via NETLINK > > * 6 ebt: ulog support > > * 7 MOXA SmartIO support > > * 8 Old I2O ioctls > > * 9 Stallion drivers > > * 10 SDL RISCom/8 support > > * 11 Macintosh M68K support > > * 12 Commodore A2232 serial support > > * 13 CONFIG_FORCED_INLINING > > * 14 kernel_thread() > > > > which of the above are legitimate candidates for removal? which are > > already underway in someone's local tree? anything else that can > > be added? etc, etc. > > > > Take a look at Documentation/feature-removal-schedule.txt > Some of that stuff is already listed there along with who is in charge > of removing it and when. Let's not get in that catfight again. That file has been demonstrated to be half too premature and half completely obsolete. He's asking for which things should he start generating and sending patches and expect them to not be ignored or angrily shot down. feature-removal-schedule.txt does not provide this information, again as has been demonstrated. Of course, it would be great if it were accurate and -did- provide that information. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"[IPV6]: Fix routing round-robin locking." breaks manual default route (bug 8349)
Initial state - address, no routes: # ip -6 a 2: eth0: mtu 1500 qlen 1000 inet6 2001:4b10:1005:0:202:44ff:fe50:91af/64 scope global valid_lft forever preferred_lft forever inet6 fe80::202:44ff:fe50:91af/64 scope link valid_lft forever preferred_lft forever # ip -6 r fe80::/64 dev eth0 metric 256 expires 21332290sec mtu 1500 advmss 1440 ff00::/8 dev eth0 metric 256 expires 21332290sec mtu 1500 advmss 1440 unreachable default dev lo proto none metric -1 error -101 # ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530 connect: Network is unreachable Adding a 2000::/3 route works: # ip -6 r a 2000::/3 via fe80::230:18ff:feb0:25c2 dev eth0 # ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530 64 bytes from 2001:4b10:1005:0:205:b4ff:fe12:530: icmp_seq=1 ttl=64 time=0.921 ms # ip -6 r d 2000::/3 via fe80::230:18ff:feb0:25c2 dev eth0 Adding a ::/0 route doesn't work: # ip -6 r a ::/0 via fe80::230:18ff:feb0:25c2 dev eth0 # ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530 connect: Network is unreachable A route assigned by addrconf works. Reverting this patch from 2.6.22-rc3 fixes it: commit f11e6659ce9058928d73ff440f9b40a818d628ab Author: David S. Miller <[EMAIL PROTECTED]> Date: Sat Mar 24 20:36:25 2007 -0700 [IPV6]: Fix routing round-robin locking. This patch is was added to 2.6.20.5, breaking -stable too. With RT6_DEBUG 3 in route.c (plus some additional debug statements): Manual default route: [ 535.981000] fib6_add_rt2node [ 535.981000] fib6_add_rt2node fn->fn_flags = 0007 (RTN_TL_ROOT=0001) [ 535.981000] fib6_add_rt2node fn->leaf = b0697be0 (ip6_null_entry = b0697be0) [ 535.981000] fib6_add_rt2node rt->rt6i_flags = 0003 (RTF_DEFAULT = 0001, RTF_ADDRCONF = 0004) [ 535.981000] fib6_add_rt2node goto out... [ 535.981000] fib6_add_rt2node out: Ping6: [ 570.903000] rt6_select(fn->leaf=b1b63140, oif=0) [ 570.903000] find_match rt->rt6i_gateway = [ 570.903000] find_match m = 10, *mpri = -1 [ 570.904000] rt6_select() => b0697be0 [ 570.904000] rt6_select(fn->leaf=b1b63140, oif=0) [ 570.904000] find_match rt->rt6i_gateway = [ 570.904000] find_match m = 10, *mpri = -1 [ 570.904000] rt6_select() => b0697be0 Addrconf default route: [ 624.846000] rt6_select(fn->leaf=b1b63300, oif=2) [ 624.846000] find_match rt->rt6i_gateway = 02ff 0100 [ 624.846000] find_match m = 10, *mpri = -1 [ 624.846000] rt6_select() => b1b63300 [ 624.846000] rt6_select(fn->leaf=b1b63300, oif=2) [ 624.846000] find_match rt->rt6i_gateway = 02ff 0100 [ 624.846000] find_match m = 10, *mpri = -1 [ 624.846000] rt6_select() => b1b63300 [ 624.846000] fib6_add_rt2node [ 624.846000] fib6_add_rt2node fn->fn_flags = 0007 (RTN_TL_ROOT=0001) [ 624.846000] fib6_add_rt2node fn->leaf = b0697be0 (ip6_null_entry = b0697be0) [ 624.846000] fib6_add_rt2node rt->rt6i_flags = 00450003 (RTF_DEFAULT = 0001, RTF_ADDRCONF = 0004) [ 624.846000] fib6_add_rt2node out: Ping6: [ 689.245000] rt6_select(fn->leaf=b1b63140, oif=0) [ 689.245000] find_match rt->rt6i_gateway = 104b0120 0510 ffb40502 300512fe [ 689.245000] find_match m = 10, *mpri = -1 [ 689.245000] rt6_select() => b1b63140 [ 689.245000] rt6_select(fn->leaf=b1b63140, oif=0) [ 689.245000] find_match rt->rt6i_gateway = 104b0120 0510 ffb40502 300512fe [ 689.245000] find_match m = 10, *mpri = -1 [ 689.245000] rt6_select() => b1b63140 [ 689.248000] rt6_select(fn->leaf=b1b63140, oif=0) [ 689.248000] find_match rt->rt6i_gateway = 104b0120 0510 ffb40502 300512fe [ 689.248000] find_match m = 10, *mpri = -1 [ 689.248000] rt6_select() => b1b63140 [ 689.248000] rt6_select(fn->leaf=b1b63140, oif=0) [ 689.248000] find_match rt->rt6i_gateway = 104b0120 0510 ffb40502 300512fe [ 689.248000] find_match m = 10, *mpri = -1 [ 689.248000] rt6_select() => b1b63140 [ 689.248000] rt6_select(fn->leaf=b1b63ae0, oif=2) [ 689.248000] find_match rt->rt6i_gateway = [ 689.248000] find_match m = 9, *mpri = -1 [ 689.248000] rt6_select() => b1b63ae0 [ 689.702000] rt6_select(fn->leaf=b1b63ae0, oif=2) [ 689.702000] find_match rt->rt6i_gateway = [ 689.702000] find_match m = 9, *mpri = -1 [ 689.702000] rt6_select() => b1b63ae0 Manual 2000::/3 route: [ 765.424000] fib6_add_rt2node [ 765.424000] fib6_add_rt2node fn->fn_flags = (RTN_TL_ROOT=0001) [ 765.424000] fib6_add_rt2node fn->leaf = (ip6_null_entry = b0697be0) [ 765.424000] fib6_add_rt2node rt->rt6i_flags = 0003 (RTF_DEFAULT = 0001, RTF_ADDRCONF = 0004) [ 765.424000] fib6_add_rt2node out: [ 765.424000] fib6_add_rt2node fn->fn_flags |= RTN_RTINFO; Ping6: [ 779.705000] rt6_select(fn->leaf=b1b63060, oif=0) [ 779.705000] find_match rt->rt6i_gateway = 80fe ff183002 c225b0fe [ 779.705000]
Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
On Monday 28 May 2007, Matthew Garrett wrote: > On Fri, Jan 05, 2007 at 10:01:57AM -0800, David Brownell wrote: > > This is an "RTC framework" driver for the "CMOS" RTCs which are standard > > on PCs and some other platforms. That's MC146818 compatible silicon. > > ... > > +static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t) > > This is awkward. At the very least, year will be set to -1. This then > gets passed through to rtc_tm_to_time, which results in reading > wakealarm providing very odd feedback. I guess the "right" fix is for > rtc_tm_to_time to use the current values for anything that's -1? Well ... legacy APIs allow "-1" there; /proc/driver/rtc certainly interprets wildcards consistently too. That is, historically it's not been legit to call rtc_tm_to_time(>time). A counter-argument could be made that rtc_read_alarm() should get rid of wildcards. It's got the right RTC in hand; rtc_tm_to_time() doesn't. Other RTCs can have this same type of "wildcard" issue. Me, I'd prefer to make the API treat alarms as purely oneshot. That whole "wildcard" model is, as you noted, awkward ... even though it's got hardware support in cases like MC146818 and clones, it's not very portable. But I don't want to push that issue either way just now. > > + rtc_control = CMOS_READ(RTC_CONTROL); > > + rtc_control &= ~(RTC_PIE | RTC_AIE | RTC_UIE); > > Do you really want to clobber RTC_AIE on probe? If an alarm has been set > by the BIOS, it seems a little unfair to disable it on boot. I was wondering about that in the context of a different RTC, which happens to run on BIOS-less hardware. Which, curiously, may be the opposite of BIOS-impaired hardware ... :) In general, I suspect the alarm should stay active ... unless its time has already passed. That was the original intent of that tweak, but of course PCs don't actually *have* oneshot alarms, so there's no way to tell if a given alarm is in the past. Leading to the conclusion that AIE should probably stay enabled. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] RTC: Use fallback IRQ if PNP tables don't provide one
On Monday 28 May 2007, Matthew Garrett wrote: > From: Matthew Garrett <[EMAIL PROTECTED]> > > Intel Macs (and possibly other machines) provide a PNP entry for the > RTC, but provide no IRQ. As a result the rtc-cmos driver doesn't allow > wakeup alarms. If the RTC is located at the legacy ioport range, assume > that it's on IRQ 8 unless the tables say otherwise. > > Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > --- > > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c > index 6085261..e24ea82 100644 > --- a/drivers/rtc/rtc-cmos.c > +++ b/drivers/rtc/rtc-cmos.c > @@ -641,9 +641,16 @@ cmos_pnp_probe(struct pnp_dev *pnp, const struct > pnp_device_id *id) >* drivers can't provide shutdown() methods to disable IRQs. >* Or better yet, fix PNP to allow those methods... >*/ > - return cmos_do_probe(>dev, > - >res.port_resource[0], > - pnp->res.irq_resource[0].start); > + if (pnp_port_start(pnp,0) == 0x70 && !pnp_irq_valid(pnp,0)) > + /* Some machines contain a PNP entry for the RTC, but > + * don't define the IRQ. It should always be safe to > + * hardcode it in these cases > + */ > + return cmos_do_probe(>dev, >res.port_resource[0], 8); > + else > + return cmos_do_probe(>dev, > + >res.port_resource[0], > + pnp->res.irq_resource[0].start); > } > > static void __exit cmos_pnp_remove(struct pnp_dev *pnp) > > -- > Matthew Garrett | [EMAIL PROTECTED] > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC_DRV_CMOS can break userspace interface
On Monday 28 May 2007, frank paulsen wrote:
> David Brownell <[EMAIL PROTECTED]> writes:
>
> > On Sunday 27 May 2007, Matthew Garrett wrote:
> >> f5f72b46c349fefcfd4421b2213c6ffb324c5e56 appears to break the userspace
> >> interface to the CMOS alarm. This could previously be accessed via
> >> /proc/acpi/alarm ...
> >
> > I was a bit surprised the ACPI team didn't have more comments on
> > that issue, myself. Thing is, all of /proc/acpi/* is deprecated
> > (scheduled for removal in barely over one month!) and nobody had
> > found any actual users of that "alarm" file when they searched for
> > them a while ago. I suppose the conclusion then was that there
> > are no applications using it.
>
> sorry for breaking the CC:, but i am currently not subscribed to lkml.
I restored both lkml and linux-acpi to the CC list. :)
> please have a look at at http://www.mythtv.org/wiki/index.php/ACPI_Wakeup
>
> i think there is quite a number of users, but most of them won't ever
> look into LKML :)
That seems to be true. And those particular users should learn the
portable /sys/class/rtc/rtc0/wakealarm syntax ... e.g. using numeric
seconds-since-epoch ("date '+%s'") instead of strings the kernel needs
to parse. That way, they can start converting usage sooner.
Someone with edit privs on that wiki should update those docs, and
tell folk to switch to that interface since the other one is going...
I'm suspecting that there should be a CONFIG_ACPI_SLEEP_PROC_ALARM
not the current internal (acpi/sleep/proc.c) HAVE_ACPI_LEGACY_ALARM,
and some way should be found that the two interfaces can coexist for
a while. But I can't quite make sense of the strategy for getting
rid of the /proc/acpi/* files ... for example, I see one entry
saying the ACPI procfs as a whole vanishes July 2007, and the next
one says that /proc/acpi/button stays until August 2007.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Add the device IDs for AMD/ATI SB700
Hi,
Sorry for the late reply and thanks to Jeff for stepping in. :)
Since Jeff covered both status of your patches and administrative issues
I would only like to add one small hint for people adding support for
multi-function PCI chipsets (with multiple PCI device IDs):
It makes sense to put addition of _all_ new PCI IDs into the first patch
of the series and send it to PCI Maintainer (Hi Greg). This should make
all other patches from the series independent of each other (in the usual
case I'm not talking about all crazy scenarios here). After the patch
with PCI IDs gets applied upstream you may now send all other patches to
the respective maintainers without worrying about inter-patch dependencies
and without maintainers worrying about your patches not applying cleanly.
IIRC Intely guys are using this process when adding support for their new
chipsets and it works smoothly.
[ Yep, this process is the exception from the general "patch shouldn't add
unused code" rule but the amount of _temporarily_ unused stuff is _minimal_
and doing it this way saves a lot of time for all parties involved. ]
PS Greg/Jeff If I'm totally wrong on this please correct me...
Thanks,
Bart
On Friday 25 May 2007, Jeff Garzik wrote:
> Henry Su wrote:
> > I check the latest kernel source code with git, and find out that the
> > SMBus patch has not been applied yet,
>
> Correct. When you don't see a patch in the upstream git tree
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> then the next step is consult the MAINTAINERS file, and determine to
> whom you should send a follow-up patch, or simply contact about the
> status of a patch you just sent. In this case, SMBus is in drivers/i2c
> sub-directory, which leads us to find in MAINTAINERS,
>
> I2C SUBSYSTEM
> P: Jean Delvare
> M: [EMAIL PROTECTED]
> L: [EMAIL PROTECTED]
> T: quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
> S: Maintained
>
> That tells us the maintainer of the subsystem, and also ("T:") an
> external reference (a tree) to where the maintainer posts accepted
> patches, prior to sending them upstream.
>
> So for SMBus, you should make sure your SMBus changes appear in Jean
> Delvare's quilt tree. If they do not, create a new patch and send it to
> Jean and CC [EMAIL PROTECTED] and [EMAIL PROTECTED]
>
>
> > and the patch for IDE has not been applied completely.one more device
> > id should be added to pata_atiixp.c,
> > l list the patch as following, or you can fetch it from the attached file,
> > could you please apply this for me?
>
> Actually it has been applied -- the part that I maintain (drivers/ata/*)
> is currently stored in a secondary tree, as described above. Your patch
> has been stored on the 'upstream' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
> Currently, the upstream Linux kernel is only accepting bug fixes. I
> merge ATA bug fixes (and sometimes simple PCI ID additions) into
> libata-dev.git#upstream-fixes during this phase of development. These
> changes are sent upstream in 24-48 hours, to ensure that they will be
> included in the next release (kernel 2.6.22).
>
> All other ATA changes are merged into libata-dev.git#upstream. When
> Linus releases kernel 2.6.22, the "merge window" opens, allowing
> non-bug-fix changes to be submitted upstream. When the merge window
> opens, I submit everything in libata-dev.git#upstream to Linus and
> Andrew Morton for inclusion in the official upstream kernel tree.
>
> That is our development process in a nutshell.
>
> The kernel development process is conducted entirely via email, so you
> see why it is so important to learn how to email patches in the proper
> format.
>
> 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 3/3] Make ide dma blacklist handling a bit saner.
Hi, On Tuesday 22 May 2007, Junio C Hamano wrote: > Earlier, the matching of (model,rev) in ide-dma black/white list > handling was to consider "ALL" in the table to match any > revision. This changes the wildcard to NULL. This way, the > DMA_BLACK_LIST macro used in the previous patch does not have to > use a slightly funky compile time constant expression to convert > NULL to "ALL". > > Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> The change itself looks good but IMO it is worth doing it before patch #2/3 (it would also make it possible for me to merge this patch immediately). When it comes to patch #2 - Alan's comment may be a bit harsh but he seems to be right - there should be a common library-like file (ata-blacklist.c or ata-quirks.c or whatever name you like) containing ata_device_blacklist[]. This would require slight modification of ide_in_drive_list() to teach it about ATA_HORKAGE_DMA but as I see from this patch this shouldn't be a problem for you. ;) Please also note that is used by both IDE and libata so it should be a good place to put struct ata_blacklist_entry and ATA_HORKAGE_* macros. Care to respin both patches? > * I do not really know what I am doing in the mips area, but >that architecture specific table seems to be used by the same >ide_in_drive_list() function, so the entries are matched to >the updated code. Yep, thanks for not breaking AMD Alchemy IDE suppport. It looks like au1xxx_ide.h should really be in drivers/ide/mips because it is only included from drivers/ide/mips/au1xxx_ide.c - could somebody verify this and send me a patch? Thanks, Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NOHZ: local_softirq_pending 08
Hi! A lot of "NOHZ: local_softirq_pending 08" messages (about 100) and then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 changelogs but I don't see anything about this message. What does it mean? Is "08" IRQ number? 8: 2XT-PIC-XTrtc Please CC me. Thank You Rafał -- Ile masz w domu niepotrzebnych rzeczy? Wymien sie z sasiadami >> http://link.interia.pl/f1a93 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: software suspend doesn't work with 2.6.22-rc3
On Monday 28 May 2007, Rafael J. Wysocki wrote: > On Monday, 28 May 2007 09:59, Rafael J. Wysocki wrote: > > On Monday, 28 May 2007 02:21, Maximilian Engelhardt wrote: > > > On Sunday 27 May 2007, Rafael J. Wysocki wrote: > > > > On Sunday, 27 May 2007 22:41, Maximilian Engelhardt wrote: > > > > > On Sunday 27 May 2007, Rafael J. Wysocki wrote: > > > > > > On Sunday, 27 May 2007 18:01, Maximilian Engelhardt wrote: > > > > > > > On Saturday 26 May 2007, Nigel Cunningham wrote: > > > > > > > > Hi. > > > > > > > > > > > > > > > > On Sat, 2007-05-26 at 14:49 +0200, Maximilian Engelhardt wrote: > > > > > > > > > On Saturday 26 May 2007, Nigel Cunningham wrote: > > > > > > > > > > Hi. > > > > > > > > > > > > > > > > > > > > On Sat, 2007-05-26 at 11:28 +0200, Maximilian Engelhardt wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > > > When I try software suspend on my laptop it always > > > > > > > > > > > returns to my running system after some time. > > > > > > > > > > > This is what's logged by the kernel: > > > > > > > > > > > > > > > > > > > > > > swsusp: Basic memory bitmaps created > > > > > > > > > > > Stopping tasks ... > > > > > > > > > > > Stopping kernel threads timed out after 20 seconds (1 > > > > > > > > > > > tasks refusing to freeze): > > > > > > > > > > > cryptd > > > > > > > > > > > Restarting tasks ... done. > > > > > > > > > > > swsusp: Basic memory bitmaps freed > > > > > > > > > > > > > > > > > > > > > > I have no idea what's the problem, but if you tell me > > > > > > > > > > > what I should do I can create debugging information > > > > > > > > > > > and/or test patches. > > > > > > > > > > > > > > > > > > > > Could you try this patch, please? It should help. > > > > > > > > > > > > > > > > > > > > Herbert, is this right? If cryptd is going to be used for > > > > > > > > > > block devs, the task should probably be PF_NOFREEZE (or > > > > > > > > > > whatever it is today) instead. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Nigel > > > > > > > > > > > > > > > > > > > > crypto/cryptd.c |1 + > > > > > > > > > > include/linux/freezer.h |3 +++ > > > > > > > > > > kernel/power/process.c |2 +- > > > > > > > > > > 3 files changed, 5 insertions(+), 1 deletion(-) > > > > > > > > > > diff -ruNp 991-fix-cryptd.patch-old/crypto/cryptd.c > > > > > > > > > > 991-fix-cryptd.patch-new/crypto/cryptd.c --- > > > > > > > > > > 991-fix-cryptd.patch-old/crypto/cryptd.c2007-05-19 > > > > > > > > > > 18:16:47.0 +1000 +++ > > > > > > > > > > 991-fix-cryptd.patch-new/crypto/cryptd.c2007-05-26 > > > > > > > > > > 19:45:42.0 +1000 @@ -341,6 +341,7 @@ static int > > > > > > > > > > cryptd_thread(void *data) > > > > > > > > > > > > > > > > > > > > mutex_unlock(>mutex); > > > > > > > > > > > > > > > > > > > > + try_to_freeze(); > > > > > > > > > > schedule(); > > > > > > > > > > } while (!stop); > > > > > > > > > > > > > > > > > > I tried your patch, but when I apply it my kernel doesn't > > > > > > > > > compile any more. I get these warnings/errors: > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > CC crypto/cryptd.o > > > > > > > > > crypto/cryptd.c: In function ‘cryptd_thread’: > > > > > > > > > crypto/cryptd.c:344: warning: implicit declaration of > > > > > > > > > function ‘try_to_freeze’ [...] > > > > > > > > > LD init/built-in.o > > > > > > > > > LD .tmp_vmlinux1 > > > > > > > > > crypto/built-in.o: In function `cryptd_thread': > > > > > > > > > cryptd.c:(.text+0xd7f5): undefined reference to > > > > > > > > > `try_to_freeze' make: *** [.tmp_vmlinux1] Error 1 > > > > > > > > > > > > > > > > Ah. You'll need to add #include near that > > > > > > > > start of crypto/cryptd.c. Sorry for forgetting that. > > > > > > > > > > > > > > > > Nigel > > > > > > > > > > > > > > I added the include line and now I could compile the kernel, > > > > > > > but suspending still doesn't work. > > > > > > > > > > > > > > swsusp: Basic memory bitmaps created > > > > > > > Stopping tasks ... > > > > > > > Stopping kernel threads timed out after 20 seconds (1 tasks > > > > > > > refusing to freeze): > > > > > > > cryptd > > > > > > > Restarting tasks ... done. > > > > > > > swsusp: Basic memory bitmaps freed > > > > > > > > > > > > OK, this means that cryptd doesn't execute the try_to_freeze() > > > > > > for some reason. > > > > > > > > > > > > Please apply the appended patch on top of 2.6.22-rc3 and see if > > > > > > that helps. > > > > > > > > > > > > Greetings, > > > > > > Rafael > > > > > > > > > > > > --- > > > > > > crypto/cryptd.c |1 + > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > Index: linux-2.6.22-rc3/crypto/cryptd.c > > > > > > = > > > > > >== --- linux-2.6.22-rc3.orig/crypto/cryptd.c > > > > > > +++ linux-2.6.22-rc3/crypto/cryptd.c > > > > > >
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
Hi! > >In fact, I'd like drivers to use notifiers to actually > >load the firmware into > >memory before hibernation/suspend. Namely, if there's > >PM_PRE_FREEZE, the > >driver calls request_firmware() from within the > >notifier and saves the firmware > >in memory for future use, if need be. Later, when > >PM_POST_THAW comes, the > >memory holding the firmware is released. > > > >Unfortunately there are drivers that call > >request_firmware() directly from > >.resume() which blocks until timeout expires and fails > >anyway. I just wanted > >this to fail immediately, without waiting. > > Stupid question time. Wouldn't it just be easier to have > request_firmware() keep a copy of the firmware once it's > been loaded? > We're not talking about a lot of memory that would be > wasted, and that > way no drivers have to be changed. Actually, I like this idea. Firmware problems magically disappear. ...unless someone uses x86 emulator in userland to POST graphics card. You can't 'cache' that. But that's separate problem. -- (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: [PATCH -mm] reiser4: remove lzo compression security hole
Richard Purdie wrote:
Switch reiser4 to use lzo1x_decompress_safe instead of lzo1x_decompress
as otherwise it presents a security hole (lzo1x_decompress doesn't
perform bounds checking on the decompressed data).
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
fs/reiser4/plugin/compress/compress.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21/fs/reiser4/plugin/compress/compress.c
===
--- linux-2.6.21.orig/fs/reiser4/plugin/compress/compress.c 2007-05-16
20:47:45.0 +0100
+++ linux-2.6.21/fs/reiser4/plugin/compress/compress.c 2007-05-24
23:43:28.0 +0100
@@ -319,7 +319,7 @@ lzo1_decompress(coa_t coa, __u8 * src_fi
assert("edward-851", coa == NULL);
assert("edward-852", src_len != 0);
- result = lzo1x_decompress(src_first, src_len, dst_first, , NULL);
+ result = lzo1x_decompress_safe(src_first, src_len, dst_first, ,
NULL);
if (result != LZO_E_OK)
warning("edward-853", "lzo1x_1_decompress failed\n");
*dst_len = dstlen;
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
Hi! > > > I can't speak for the second example, but there's a good reason the > > > first example works this way. It's not a matter of races; the problem > > > is that the kernel thread's job is to selectively suspend and resume > > > devices. We don't want it doing this while a system sleep is in > > > progress; it would (and in fact has, before the thread was made > > > freezable) cause the sleep transition to abort. > > > > How does this work on PPC or APM systems? > > For hibernation it behaves the same as on other types of systems. > > For STR it generally works okay. There was one report of suspends > aborting, and it looked like this was caused by selective resumes > originating from userspace. This seemed to be unrelated to the kernel > threads; apparently some program was running while the STR was in > progress, and causing the problem. For example, the lsusb program will > do a selective resume on every USB device as it scans through them all. > However that's just a guess, we haven't fully resolved that bug report. > > The theoretical answer is that it behaves the way we want. The kernel > thread does selective resumes in response to device requests. If such > a request comes in while the system is asleep it will awaken the > system; so it's only logical that a request coming in while the system > is in the process of going to sleep should abort the suspend. I'd say that it shows ppc being broken. User wanted to suspend the system, and now unrelated task did lsusb... and system will not sleep. AFAICT it is DoS issue -- if one of your users keeps doing lsusb, root will not be able to suspend the system. 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/
[PATCH] Fix potential memory leak in tipc_named_node_up()
There seems to be a memory leak in net/tipc/name_distr.c::tipc_named_node_up()
The function, with comments, is this :
void tipc_named_node_up(unsigned long node)
{
struct publication *publ;
struct distr_item *item = NULL;
struct sk_buff *buf = NULL;
u32 left = 0;
u32 rest;
u32 max_item_buf;
read_lock_bh(_nametbl_lock);
max_item_buf = TIPC_MAX_USER_MSG_SIZE / ITEM_SIZE;
max_item_buf *= ITEM_SIZE;
rest = publ_cnt * ITEM_SIZE;
list_for_each_entry(publ, _root, local_list) {
-> If we stop processing here after doing 1, 2 & 3 below we end up at (4)
(below).
if (!buf) {
left = (rest <= max_item_buf) ? rest : max_item_buf;
rest -= left;
buf = named_prepare_buf(PUBLICATION, left, node);
-> (1) here we allocate memory and store a pointer to it in 'buf'.
if (!buf) {
-> (2) This test needs to fail, meaning we did allocate some memory.
warn("Bulk publication distribution failure\n");
goto exit;
}
item = (struct distr_item *)msg_data(buf_msg(buf));
}
publ_to_item(item, publ);
item++;
left -= ITEM_SIZE;
if (!left) {
-> (3) If this test fails we loop and do nothing to 'buf'.
msg_set_link_selector(buf_msg(buf), node);
dbg("tipc_named_node_up: sending publish msg to "
"<%u.%u.%u>\n", tipc_zone(node),
tipc_cluster(node), tipc_node(node));
tipc_link_send(buf, node, node);
buf = NULL;
}
}
exit:
read_unlock_bh(_nametbl_lock);
-> (4) here we return without freeing 'buf' - memory leak.
}
Luckily this is easy to fix, since we can only leave the function with 'buf'
either set to NULL or (in the leak case) set to a valid address, and since
kfree() handles being passed NULL gracefully we can simply kfree(buf) just
before we leave the function.
The patch below frees 'buf' before leaving the function, thus avoiding the
potential leak.
Fix a potential memory leak in tipc_named_node_up()
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
net/tipc/name_distr.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index 39fd161..228ccfe 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -204,6 +204,7 @@ void tipc_named_node_up(unsigned long node)
}
exit:
read_unlock_bh(_nametbl_lock);
+ kfree(buf);
}
/**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] enhancing the kernel's graphics subsystem
On 5/28/07, Pavel Machek <[EMAIL PROTECTED]> wrote: Hi! > >> These are not isolated problems. Linux needs a > >properly designed > >> graphics subsystem. One way to achieve that is to > >design it all on > >> paper first so that we can try and locate the > >interactions between > >> modules. For example the current mode setting design > >is definitely > >> broken for multi-seat support, that's because you > >didn't take that > >> feature into account when writing the code. > > > >No it isn't the code Jesse posted can handle multi-seat > >fine in the > >areas that it makes sense as we've pointed out to you > >you cannot just > > The code doesn't create one device per CRTC. Missing > that feature > means that we need a persistent root priv app around > that owns the > single device and then listens for messages from each > seat asking it > to do things. That root priv app is not necessary, it is > a security > risk and it should be eliminated. Fine, submit a patch. But don't block other people patches just because they do not address your favourite problem. I have already implemented this once and submitted a patch. Search in the paper for this paragraph: http://jonsmirl.googlepages.com/graphics.html DRM also implements the concept of a master user with more capabilities than normal users. These extra capabilities allow the graphics device to be initialized and the consumption of GPU resources to be controlled. The current X server, which runs as root, functions as the DRM master. There is actually no real requirement that the DRM master be run as root, and there is a preliminary patch that removes this requirement. That paragraphs contains a link to the code that used to be hosted at freedesktop.org. Maybe they can still find it. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: b44: regression in 2.6.22 (resend)
On Monday 28 May 2007, Thomas Gleixner wrote: > On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote: > > > Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the > > > following combinations on the kernel command line: > > > > > > 1) highres=off nohz=off (should be the same as your working config) > > > 2) highres=off > > > 3) nohz=off > > > > I tested this with my 2.6.22-rc3 kernel, here are the results: > > > > without any special boot parameters: problem does appear > > highres=off nohz=off: problem does not appear > > highres=off: problem does not appear > > nohz=off: problem does appear > > Is there any other strange behavior of the high res enabled kernel than > the b44 problem ? I didn't notice anything. > > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution > > Timer, but the high ping problem is still there. > > Hmm, that's mysterious. Wild guess is that highres exposes the hidden > "feature" in a different way than rc2-mm1 does. I think the bug in 2.6.21/22-rc3 is a different one that the one in 2.6.22-rc2-mm1, but that's also only a wild guess :) I'll explain this a bit: In 2.6.21/22-rc3 is the same b44 driver that has been in the stock kernels for some time. With this driver and High Resolution Timer turned on I get problems using iperf. The problems are that the systems becomes really slow and unresponsive. Michael Buesch thought this could be an IRQ storm which sounds logical to me. This bug did never happen to me before I startet the iperf test. The other issue happens only with 2.6.22-rc2-mm1 which includes the b44 ssb spilt. It's independed wether High Resolution Timer is turned on or off I always get very varying and high ping times. The iperf-test doesn't show the problems from 2.6.21/22-rc3. Maxi signature.asc Description: This is a digitally signed message part.
Re: stuff ready to be deleted?
On Mon, 28 May 2007, Oliver Pinter wrote: > + open sound system yeah, that one's so obvious, i don't even list it anymore. :-) i'm assuming adrian's going to deal with that when the time comes. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO de/compression support - take 6
On Monday 28 May 2007 16:18:40 Daniel Hazelton wrote: > On Monday 28 May 2007 13:11:15 Adrian Bunk wrote: > > On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote: > > > On 5/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > >... > > > > > >> - then ensure that it works correctly on all architectures and > > > > > > Already tested on x86, amd64, ppc (by Bret). I do not have machines > > > from other archs available. Bret tested 'take 3' version but no > > > changes were introduced in further revisions that could affect > > > correctness - but still it will be good to have this version tested > > > too. Only with inclusion in -mm and testing by much wider user base > > > can make it to mainline (I suppose nobody uses -mm for production use > > > anyway). > > > > > >> document why your version is that much faster than the original > > >> version and why you know your optimizations have no side effects > > With likely(), unlikely() and noinline *not* defined as NOP's performance > drops: > > 1 run averages: > 'Tiny LZO': > Combined: 84.9292 usec > Compression: 42.4646 usec > Decompression: 42.4646 usec > 'miniLZO': > Combined: 61.3548 usec > Compression: 43.5648 usec > Decompression: 17.79 usec > > However, I'm worried that my testbed code - likely the Perl script that > actually loops the test code and collects its output - is somehow faulting, > as the way that the Compression and Decompression code have the exact same > value. > > I'm going to toss some debugging output in the script and see if I can spot > the problem. > Okay, checked my code and it was all a problem with cpu_to_le16 getting defined fully instead of just being a NOP. With that problem corrected the performance returns: 1 run averages: 'Tiny LZO': Combined: 60.1028 usec Compression: 42.0652 usec Decompression: 18.0376 usec 'miniLZO': Combined: 61.0932 usec Compression: 43.4382 usec Decompression: 17.655 usec Combined average shows 'Tiny' to be 1.6% faster Compression in 'Tiny' is 3.2% faster Decompression in 'Tiny' is 2.2% slower All in all, the trade-off in this code, with the overall performance of the 'Tiny' code being faster than the stock miniLZO code I'd like to say that I'm certain that the decompressor could probably be sped up more, although I don't know of a place in the kernel where less than half a microsecond would make a massive impact. (Only place I can think of where this might have a negative is in SLAB/SLOB/SLUB, and I don't think that a low-level memory manager like those is a place for a compression algorithm anyway) Later today or tommorrow I'll start putting together another part to this "test-bed" for stress-testing the algorithm. Currently I only have a few ideas for tests: (for benchmarking) 1) Random input to compressor 2) large input data 3) real-world data (mmap()'d chunk of /dev/mem as input) (for stability checking) 4) deliberate corruption of compressed data 5) early finish (realloc() compressed data buffer to less than the full size of the data) 6) late start (change pointer to start of compressed data so the decompressor doesn't start at the beginning) When I have a better idea of how the LZO algorithm works I might try creating an input data-set for the decompressor that would deliberately overflow the output buffer. This is supposed to be caught by bounds-checking in the '_safe' version of the decompressor (the version used in 'Tiny' and used in the benchmarking of miniLZO), however it might be possible to trick the decompressor. (If I do manage this and it crashes both 'Tiny' and 'miniLZO' I *will* report it to Herr Oberhumer as well as see if I can come up with a quick patch for the problem). As I said before, any suggestions for how to improve the benchmark code are welcome, as are suggestions for tests I can add to it for stressing the new 'TinyLZO' implementation. Latest version of the test-bed attached. Significant changes include: likely(), unlikely() and noinline are no longer NOP's when the marked line in helpers.h is commented out, cpu_to_le16 functions as expected and is no longer a NOP. (Yes, that means this code is now fully capable of working correctly on a BE system). DRH lzo1x-test-bed-5.tar.bz2 Description: application/tbz
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 5/28/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: On Monday, 28 May 2007 17:55, Alan Stern wrote: > You're using the PM_PRE_FREEZE and PM_POST_THAW notifiers for both this > and the userspace helper change. Is it your intention that drivers > should continue to request these services but encounter an error if the > request occurs at the wrong time? Or do you expect drivers to use the > notifier chains to know when they shouldn't make any requests? In fact, I'd like drivers to use notifiers to actually load the firmware into memory before hibernation/suspend. Namely, if there's PM_PRE_FREEZE, the driver calls request_firmware() from within the notifier and saves the firmware in memory for future use, if need be. Later, when PM_POST_THAW comes, the memory holding the firmware is released. Unfortunately there are drivers that call request_firmware() directly from .resume() which blocks until timeout expires and fails anyway. I just wanted this to fail immediately, without waiting. Stupid question time. Wouldn't it just be easier to have request_firmware() keep a copy of the firmware once it's been loaded? We're not talking about a lot of memory that would be wasted, and that way no drivers have to be changed. Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: stuff ready to be deleted?
+ open sound system - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Hi! > >>That's a circular argument, and a fairly trivial one > >>at that. If you > >>can't properly manage your labels, then how do you > >>expect any > >>security at all? > > > >Unfortunately, it's not at all as simple as all that. > >Toshiharu is quite correct that it isn't always easy > >to actually implement. Consider how many ad-croc > >usages of 'restorecon' are needed to get a Fedora > >SELinux box through rc.sysinit: > > While I don't think restorecon is really necessary to > properly boot SELinux-enabled (I've got a Debian box > with some heavily customized policy which does so just > fine), I am of the opinion that adding a "name" > parameter to the file/directory create actions would be > useful. For example, with such support you could > actually specify a type-transition rule conditional on > a specific name or substring: > > named_type_transition sshd_t tmp_t:sock_file prefix > "ssh-" ssh_sock_t; > > Useful options for matching would be "prefix", "suffix", > "substr (start,len)". "regex" would be nice but is > sorta computationally intensive and would be likely to > cause more problems than it solves. Could someone implement this? AFAICT that prevents SELinux from being superset of AppArmor... Doing this should be significantly simpler than whole AA, and hopefully it will end up less ugly, too. -- (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: ARM: Section mismatch warnings
On Mon, May 28, 2007 at 09:58:47PM +0200, Sam Ravnborg wrote: > Declaring neponset_probe __init cured it. > Sorry for posting the wrong patch in the first place. Arguably, making neponset_probe __devinit and neponset_port_fns __devinitdata is arguably more correct since any device driver can be bound and unbound at any time (grumble). I don't think David's platform_driver_probe() is a proper answer since it's still possible to unbind the driver, leaving no way to re-bind. IOW, it only solves half the problem. Really, the allowance of bind/unbind should be a per-driver and per-bus thing imho. That's for a separate discussion though. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: stuff ready to be deleted?
On 28/05/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: i'm trying to keep track of kernel janitor projects that involve removing dead content from the tree: http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List currently, the list contains the items: * 1 Legacy power management * 2 PCMCIA IOCTL support * 3 Traffic shaper * 4 Traffic policing * 5 Userspace queueing via NETLINK * 6 ebt: ulog support * 7 MOXA SmartIO support * 8 Old I2O ioctls * 9 Stallion drivers * 10 SDL RISCom/8 support * 11 Macintosh M68K support * 12 Commodore A2232 serial support * 13 CONFIG_FORCED_INLINING * 14 kernel_thread() which of the above are legitimate candidates for removal? which are already underway in someone's local tree? anything else that can be added? etc, etc. Take a look at Documentation/feature-removal-schedule.txt Some of that stuff is already listed there along with who is in charge of removing it and when. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: [RFC] LZO de/compression support - take 6
On Monday 28 May 2007 13:11:15 Adrian Bunk wrote: > On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote: > > On 5/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > >... > > > >> - then ensure that it works correctly on all architectures and > > > > Already tested on x86, amd64, ppc (by Bret). I do not have machines > > from other archs available. Bret tested 'take 3' version but no > > changes were introduced in further revisions that could affect > > correctness - but still it will be good to have this version tested > > too. Only with inclusion in -mm and testing by much wider user base > > can make it to mainline (I suppose nobody uses -mm for production use > > anyway). > > > >> document why your version is that much faster than the original > >> version and why you know your optimizations have no side effects With likely(), unlikely() and noinline *not* defined as NOP's performance drops: 1 run averages: 'Tiny LZO': Combined: 84.9292 usec Compression: 42.4646 usec Decompression: 42.4646 usec 'miniLZO': Combined: 61.3548 usec Compression: 43.5648 usec Decompression: 17.79 usec However, I'm worried that my testbed code - likely the Perl script that actually loops the test code and collects its output - is somehow faulting, as the way that the Compression and Decompression code have the exact same value. I'm going to toss some debugging output in the script and see if I can spot the problem. DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
stuff ready to be deleted?
i'm trying to keep track of kernel janitor projects that involve removing dead content from the tree: http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List currently, the list contains the items: * 1 Legacy power management * 2 PCMCIA IOCTL support * 3 Traffic shaper * 4 Traffic policing * 5 Userspace queueing via NETLINK * 6 ebt: ulog support * 7 MOXA SmartIO support * 8 Old I2O ioctls * 9 Stallion drivers * 10 SDL RISCom/8 support * 11 Macintosh M68K support * 12 Commodore A2232 serial support * 13 CONFIG_FORCED_INLINING * 14 kernel_thread() which of the above are legitimate candidates for removal? which are already underway in someone's local tree? anything else that can be added? etc, etc. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
