* Re: [PATCH] CRED: Fix regression in cap_capable() as shown up by sys_faccessat() [ver #2]
From: David Howells @ 2009-01-03 23:03 UTC (permalink / raw)
To: J. Bruce Fields
Cc: dhowells, Christoph Hellwig, jmorris, linux-kernel, linux-fsdevel
In-Reply-To: <20090103184921.GB20166@fieldses.org>
J. Bruce Fields <bfields@fieldses.org> wrote:
> More precisely:
> - The last working commit is b6dff3ec... "CRED: Separate task
> security context from task_struct".
> - The first commit exhibiting the permissions problem is
> a6f76f2... "CRED: Make execve() take advantage of
> copy-on-write credentials".
> - The 9 commits in between (from f1752eec to d84f4f9) result in
> a soft lookup on boot.
Okay, I'll have a look at that, but did you manage to find out if the patch I
posted fixed the problem you originally mentioned?
David
^ permalink raw reply
* New Year 2009!
From: Ronald @ 2009-01-03 22:59 UTC (permalink / raw)
To: linux-acpi
Ronald has mailed to you Happy New Year greeting.
Just click on the following Internet address:
http://newyearcardservice.com/?cardid=7ac3d224a3112059
Thanks for Using Cardweaver.com!
^ permalink raw reply
* Re: Power Management with rootfs on SDMMC.
From: Alan Cox @ 2009-01-03 23:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pavel Machek, Andreas Mohr, Sriram V, Pierre Ossman, linux-kernel
In-Reply-To: <alpine.LFD.2.00.0901031306150.3179@localhost.localdomain>
> Well, it goes both ways. You can make a nasty mess right now by suspending
> and simply not having a working computer when it comes back - all your
> work being lost.
Yes but these are both symptoms of the same problem.
> they actually get things right is pretty low, though. So I suspect we'd be
> much better off having sane defaults in the kernel instead.
I don't believe "auto-destroy my music collection" is a sane default...
> So it boils down to the fact that if you have something like / or /home
> mounted, we really _cannot_ do any better than "assume the user doesn't
> screw us up".
>
> A per-filesystem callback to re-verify at resume might be a good idea, but
> a lot of filesystems cannot reasonably do a lot of verification.
A per file system sync and quiesce is I think also part of the
requirement. Having the file system media consistent but still mounted
before suspending is a good thing anyway (especially with stuff like USB
keys that people do then go and remove post suspend) and you can put the
device into a consistent state and revalidate it *regardless* of the
whether it is / or a music player. What you do if revalidating / fails is
another question ;)
Alan
^ permalink raw reply
* Wishing you the Best New Year!
From: Joseph @ 2009-01-03 23:00 UTC (permalink / raw)
To: git
Joseph mailed a New Year greeting card.
Click the above link to view the page! If you can't click it, copy and paste it
into your browser: http://bestyearcard.com/?ID=ba49b43e98ec608b3e653aa082186
Copyright (c) HallmarkCards All Rights Reserved
^ permalink raw reply
* Re: [RFC][PATCH] ipset - remove binding support
From: Jozsef Kadlecsik @ 2009-01-03 23:12 UTC (permalink / raw)
To: Andreas Schultz; +Cc: netfilter-devel
In-Reply-To: <1230654806.10747.6.camel@ws-aschultz>
Hi Andreas,
On Tue, 30 Dec 2008, Andreas Schultz wrote:
> Whenever i'm playing with ipset (coding), i stumble over the binding
> stuff. This has been depreciated since 2.4.0 and i think it's time to
> start doing some work for the next major release.
>
> So here is a patch that removes the binding support from ipset. I have
> tried to only remove stuff without changing to much else. Once binding
> is gone, some function calls and APIs can be simplified. But this should
> IMHO go into a separate patch.
If ipset internal structure remained the same, then according to the
planned course your patch (i.e. removing binding) would be the proper next
step. However the internals are being completely rewritten, mainly due to
changing the kernel-userspace communication channel from sockopt to
netlink. According to the planned timetable the new version will be out in
the first quarter of this year, as development release. (The current
branch as stable one will be maintained for a while.)
So - unless you have already got something developed on top of ipset -,
I'd better not apply your patch. But if you have got something ready,
just ping me. Otherwise just give me some time and there'll be a new
branch with a new API, without binding.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: document ext3 requirements
From: Duane Griffin @ 2009-01-03 23:12 UTC (permalink / raw)
To: Pavel Machek
Cc: Martin MOKREJŠ, kernel list, Andrew Morton, tytso,
mtk.manpages, rdunlap, linux-doc
In-Reply-To: <20090103222957.GG1666@elf.ucw.cz>
2009/1/3 Pavel Machek <pavel@suse.cz>:
> On Sat 2009-01-03 22:17:15, Duane Griffin wrote:
>> [Fixed top-posting]
>>
>> 2009/1/3 Martin MOKREJŠ <mmokrejs@ribosome.natur.cuni.cz>:
>> > Pavel Machek wrote:
>> >> readonly mount does actually write to the media in some cases. Document that.
>> >>
>> > Can one avoid replay of the journal then if it would be unclean?
>> > Just curious.
>>
>> Nope. If the underlying block device is read-only then mounting the
>> filesystem will fail. I tried to fix this some time ago, and have a
>> set of patches that almost always work, but "almost always" isn't good
>> enough. Unfortunately I never managed to figure out a way to finish it
>> off without disgusting hacks or major surgery.
>
> Uhuh, can you just ignore the journal and mount it anyway?
> ...basically treating it like an ext2?
I'm afraid not, ext2 won't mount an FS with EXT3_FEATURE_INCOMPAT_RECOVER set.
> ...ok, that will present "old" version of the filesystem to the
> user... violating fsync() semantics.
>
> Still handy for recovering badly broken filesystems, I'd say.
>
> Pavel
Cheers,
Duane.
--
"I never could learn to drink that blood and call it wine" - Bob Dylan
^ permalink raw reply
* Re: atomics: document that linux expects certain atomic behaviour from unsigned long
From: Alan Cox @ 2009-01-03 23:14 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list, Andrew Morton, mtk.manpages, rdunlap, linux-doc
In-Reply-To: <20090103205628.GE1666@elf.ucw.cz>
> Is there concrete architecture where it breaks? I'd expect i386/x86-64
> to be safe, and pretty much everyone to be safe as long as that long
> is aligned.... or that was the result of arch-maintainers
> discussion...
It'll break on x86 if gcc decides to cache the value and you don't have
explicit barriers. If the long is not aligned it's not safe on x86 at all.
> I'd really like to document if it is right or not, so that I can point
> people to documentation...
We should always tell people to use atomic/set_bit etc. There *are* cases
you can get away with it but it is far far better that the default is the
safe one because most driver writers do not have a detailed knowledge of
gcc code generation, processor quirks and barriers. If in a specific case
its a performance hit then its worth optimising that case.
Alan
^ permalink raw reply
* Re: [PATCH v2] Add -ftabstop=WIDTH
From: Christopher Li @ 2009-01-03 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux-sparse, Alexey Zaytsev
In-Reply-To: <7v7i5c7g5b.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 3, 2009 at 4:01 AM, Junio C Hamano <junio@pobox.com> wrote:
> "Hannes Eder" <hannes@hanneseder.net> writes:
>
>> diff --git a/lib.c b/lib.c
>> index 059ba3b..221e7b8 100644
>> --- a/lib.c
>> +++ b/lib.c
>> @@ -15,6 +15,8 @@
>> #include <string.h>
>> #include <unistd.h>
>> #include <assert.h>
>> +#include <limits.h>
>> +#include <errno.h>
>
> These includes after Chris's simplification should not be needed, no?
Good catch. I incorporate it as well.
While you are here. I have a question regarding how to publish patch series
with git.
Take this patch as example. I want to have some repository to allow
others to pull the early version of the patch for testing. I also want
to incorporate
changes into the patch itself.
If I am using patch series. That is easy, just republish a new series.
With git, I can:
1) always submit incremental changes to master branch. Then the patch will
be fragmented. I want the clean up version of the history.
2) Use rebase or cherry-pick to update the master branch. That will change
the history of the commit. it causes trouble for people who pull the earlier
version of the patch.
3) Always use a new branch to publish a new patch series. Then people who
pull it need to know which branch to pull. It seems that I want an alias for
the branch. On the client side it can use the same alias to pull different
branch. I haven't figure out how to do that with git yet.
Any suggestions?
Thanks
Chris
^ permalink raw reply
* Re: Corrupt data - RAID sata_sil 3114 chip
From: Robert Hancock @ 2009-01-03 23:23 UTC (permalink / raw)
To: Bernd Schubert
Cc: Alan Cox, Justin Piszcz, debian-user, linux-raid, linux-ide
In-Reply-To: <20090103211147.GA3707@lanczos.q-leap.de>
Bernd Schubert wrote:
> On Sat, Jan 03, 2009 at 02:53:09PM -0600, Robert Hancock wrote:
>> Bernd Schubert wrote:
>>> [sorry sent again, since Robert dropped all mailing list CCs and I
>>> didn't notice first]
>>>
>>> On Sat, Jan 03, 2009 at 12:31:12PM -0600, Robert Hancock wrote:
>>>> Bernd Schubert wrote:
>>>>> On Sat, Jan 03, 2009 at 01:39:36PM +0000, Alan Cox wrote:
>>>>>> On Fri, 2 Jan 2009 22:30:07 +0100
>>>>>> Bernd Schubert <bs@q-leap.de> wrote:
>>>>>>
>>>>>>> Hello Bengt,
>>>>>>>
>>>>>>> sil3114 is known to cause data corruption with some disks.
>>>>>> News to me. There are a few people with lots of SI and other devices
>>>>> No no, you just forgot about it, since you even reviewed the patches ;)
>>>>>
>>>>> http://lkml.org/lkml/2007/10/11/137
>>>> And Jeff explained why they were not merged:
>>>>
>>>> http://lkml.org/lkml/2007/10/11/166
>>>>
>>>> All the patch does is try to reduce the speed impact of the
>>>> workaround. But as was pointed out, they don't reliably solve the
>>>> problem the workaround is trying to fix, and besides, the workaround
>>>> is already not applied to SiI3114 at all, as it is apparently not
>>>> applicable on that controller (only 3112).
>>> Well, do they reliable solve the problem in our case (before taking the patch
>>> into production I run a checksum tests for about 2 weeks). Anyway, I entirely
>>> understand the patches didn't get accepted.
>>>
>>> But now more than a year has passed again without doing anything
>>> about it and actually this is what I strongly criticize. Most people don't
>>> know about issues like that and don't run file checksum tests as I now always
>>> do before taking a disk into production. So users are exposed to known
>>> data corruption problems without even being warned about it. Usually
>>> even backups don't help, since one creates a backup of the corrupted data.
>>>
>>> So IMHO, the driver should be deactived for sil3114 until a real
>>> solution is found. And it only should be possible to force activate it
>>> by a kernel flag, which then also would print a huuuge warning about
>>> possible data corruption (unfortunately most distributions disables
>>> inital kernel messages *grumble*).
>> If the corruption was happening on all such controllers then people
>> would have been complaining in droves and something would have been
>> done. It seems much more likely that in this case the problem is some
>> kind of hardware fault or combination of hardware which is causing the
>> problem. Unfortunately these kind of not-easily-reproducible issues tend
>> to be very hard to track down.
>>
>
> Well yes, it only happens with certain drives. But these drives work fine on
> other controllers. But still these are by now
> known issues and nothing is done for that.
> I would happily help to solve the problem, I just don't have any knowledge
> about hardware programming. What would be your next step, if you had remote
> access to such a system?
Have you been able to track down what kind of corruption is occurring
exactly, i.e. what is happening to the data, is data being zeroed out,
random bits being flipped, chunks of a certain size being corrupted,
etc. That would likely be useful in determining where to go next..
^ permalink raw reply
* Re: [TRIVIAL PATCH 00/11] Fix misspelling of "firmware"
From: Jiri Kosina @ 2009-01-03 23:23 UTC (permalink / raw)
To: Nick Andrew; +Cc: Trivial Kernel Patches, Linux Kernel Mailing List
In-Reply-To: <20090103074923.27466.7287.stgit@marcab.local>
On Sat, 3 Jan 2009, Nick Andrew wrote:
> Fix misspellings of "firmware" which I noticed in 2.6.28. All are
> comment changes except for the change to drivers/scsi/qla4xxx/ql4_mbx.c
> which is in a string argument to dev_info().
>
> Nick.
> ---
>
> Nick Andrew (11):
> Fix misspelling of "firmware" in docs for ncr53c8xx/sym53c8xx
> Fix misspelling of "firmware" in powerpc Makefile
> Fix misspelling of "firmware" in usb.c
> Fix misspelling of "firmware" in qla1280.c
> Fix misspelling of "firmware" in a100u2w.c
> Fix misspelling of "firmware" in megaraid.c
> Fix misspelling of "firmware" in ql4_mbx.c
> Fix misspelling of "firmware" in acpi_memhotplug.c
> Fix misspelling of "firmware" in ipw2100.c
> Fix misspelling of "firmware" in atmel.c
> Fix misspelled firmware in Kconfig
>
>
> Documentation/scsi/ChangeLog.ncr53c8xx | 2 +-
> Documentation/scsi/ChangeLog.sym53c8xx | 2 +-
> arch/powerpc/boot/Makefile | 2 +-
> drivers/acpi/acpi_memhotplug.c | 2 +-
> drivers/base/Kconfig | 2 +-
> drivers/net/wireless/atmel.c | 2 +-
> drivers/net/wireless/ipw2100.c | 2 +-
> drivers/scsi/a100u2w.c | 2 +-
> drivers/scsi/megaraid.c | 4 ++--
> drivers/scsi/qla1280.c | 4 ++--
> drivers/scsi/qla4xxx/ql4_mbx.c | 2 +-
> drivers/uwb/i1480/dfu/usb.c | 2 +-
> 12 files changed, 14 insertions(+), 14 deletions(-)
Thanks Nick, I have queued the patches in the trivial tree.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Documentation/x86/boot.txt:payload length was changed to payload_length
From: Jiri Kosina @ 2009-01-03 23:25 UTC (permalink / raw)
To: Baodong Chen, Ingo Molnar; +Cc: linux-kernel, trivial
In-Reply-To: <d204e3110901022037i4c0e077ck6cefcf35f6048318@mail.gmail.com>
[ added Ingo to CC ]
Ingo, I guess you are going to take the patch through x86 tree, so I
wouldn't bother merging it through trivial tree, right?
Thanks.
--
Jiri Kosina
On Sat, 3 Jan 2009, Baodong Chen wrote:
> Signed-off-by: Baodong Chen <[email]chenbdchenbd@gmail.com[email]>
>
> ---
> Documentation/x86/boot.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
> index fcdc62b..7b4596a 100644
> --- a/Documentation/x86/boot.txt
> +++ b/Documentation/x86/boot.txt
> @@ -44,7 +44,7 @@ Protocol 2.07: (Kernel 2.6.24) Added paravirtualised
> boot protocol.
> and KEEP_SEGMENTS flag in load_flags.
>
> Protocol 2.08: (Kernel 2.6.26) Added crc32 checksum and ELF format
> - payload. Introduced payload_offset and payload length
> + payload. Introduced payload_offset and payload_length
> fields to aid in locating the payload.
>
> Protocol 2.09: (Kernel 2.6.26) Added a field of 64-bit physical
> --
> 1.5.3.3
>
^ permalink raw reply
* [PATCH 1/1] x86_64: fix RIP printout in early_idt_handler
From: Jiri Slaby @ 2009-01-03 23:27 UTC (permalink / raw)
To: mingo; +Cc: linux-kernel, Jiri Slaby, Thomas Gleixner, H. Peter Anvin
Since errorcode is popped out, RIP is on the top of the stack.
Use real RIP value instead of wrong CS.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
---
arch/x86/kernel/head_64.S | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 26cfdc1..0e275d4 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -305,7 +305,7 @@ ENTRY(early_idt_handler)
call dump_stack
#ifdef CONFIG_KALLSYMS
leaq early_idt_ripmsg(%rip),%rdi
- movq 8(%rsp),%rsi # get rip again
+ movq 0(%rsp),%rsi # get rip again
call __print_symbol
#endif
#endif /* EARLY_PRINTK */
--
1.6.0.6
^ permalink raw reply related
* Fwd: Raid 5 --grow to fewer, larger drives
From: Jeff Rippy @ 2009-01-03 23:27 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <de6d3ea90901031521va35b7b5uf3050995561592c0@mail.gmail.com>
I too am looking at this. My current setup is 4x 500GB drives and I
want to move to 3x >=1TB drives.
My usable space should increase from 1.5TB to >= 2TB with this move if possible.
I'm fairly new to linux-raid in general but I know you can replace
drives with bigger ones. You just can't use their space until all
drives in the array are of that size. So I'm thinking of replacing 3
of the 500's with the 1 TBs. Then fail and remove the 4th drive
(assuming enough free space) and somehow forcing a reshape on the
remaining 3 drives. Not sure if that is possible but I can't imagine
why it wouldn't be. After the resync, finally grow to the new size
and be done.
Can someone tell me if this is even possible? I saw the one reply in
Nov. to Alex's email but I don't have another machine to swap the
disks too.
^ permalink raw reply
* Re: [PATCH] Fix small typo in bio.h's documentation
From: Jiri Kosina @ 2009-01-03 23:29 UTC (permalink / raw)
To: Alberto Bertogli; +Cc: axboe, linux-kernel, trivial, corbet
In-Reply-To: <1230591376-9001-1-git-send-email-albertito@blitiri.com.ar>
On Mon, 29 Dec 2008, Alberto Bertogli wrote:
> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
> ---
> include/linux/bio.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index 6a64209..b29e2b3 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -135,7 +135,7 @@ struct bio {
> * bit 1 -- rw-ahead when set
> * bit 2 -- barrier
> * Insert a serialization point in the IO queue, forcing previously
> - * submitted IO to be completed before this oen is issued.
> + * submitted IO to be completed before this one is issued.
> * bit 3 -- synchronous I/O hint: the block layer will unplug immediately
> * Note that this does NOT indicate that the IO itself is sync, just
> * that the block layer will not postpone issue of this IO by plugging.
> --
> 1.6.1.302.gccd4d
Has anyone merged this patch through his tree (Jens or Documentation
people?). If not, I will take it through trivial tree.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH][TRIVIAL] Add a space (and a comma) to a printk
From: Jiri Kosina @ 2009-01-03 23:32 UTC (permalink / raw)
To: Paul Bolle; +Cc: trivial, linux-kernel
In-Reply-To: <1230642403.13647.31.camel@test.thuisdomein>
On Tue, 30 Dec 2008, Paul Bolle wrote:
> Commit d87a6d9 ("drivers/serial/: remove CVS keywords") removed one
> space too many in the printk in serial8250_init(). Put it back in (and
> add a comma for clarity).
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index 303272a..31b3c08 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -3018,7 +3018,7 @@ static int __init serial8250_init(void)
> if (nr_uarts > UART_NR)
> nr_uarts = UART_NR;
>
> - printk(KERN_INFO "Serial: 8250/16550 driver"
> + printk(KERN_INFO "Serial: 8250/16550 driver, "
> "%d ports, IRQ sharing %sabled\n", nr_uarts,
> share_irqs ? "en" : "dis");
Queued in trivial tree, thanks Paul.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: Alexander Potashev @ 2009-01-03 23:32 UTC (permalink / raw)
To: Marc Weber, git; +Cc: Rogan Dawes, martin f krafft
In-Reply-To: <20081121133828.GB5912@gmx.de>
On 14:38 Fri 21 Nov , Marc Weber wrote:
> Use case:
>
> I've been reading parts of the topGit code. And it does make for it to
> add its own checks. However having to change the existing scripts
> insterting a call to the tg hooks isn't the best way.
> Why? one is using #/bin/sh the next is using #/bin/ruby maybe..
>
> So what about allowing (or even enforcing) ths directory layout?
>
> .git/hooks/pre-commit/hook1.sh
> .git/hooks/pre-commit/hook2.sh
> .git/hooks/pre-commit/topGitcheck.sh
>
> instead of
> .git/hooks/pre-commit # <- the one and only pre-commit hook
>
> so that all can be run in squence?
If we have a single hook, git just runs a script. But multiple scripts
can be run in different orders. We can assume that git should run them
in lexicographical order, but sometimes it's not the best order can be
used.
However, prefixes can be used to force a particular lexicographical
order:
.git/hooks/pre-commit/01-hook2.sh
.git/hooks/pre-commit/02-topGitcheck.sh
.git/hooks/pre-commit/03-hook1.sh
Is there a better way to choose the scripts order?
>
> This way you can keep the original git sample files and update them
> while adding you very own checks more easily.
>
> But maybe this isn't the best choice either and the way to go is
>
> .git/hooks/list-of-hook-directories # eg containing ".git/hooks/samples\n.git/hooks/topgit" ?
>
> .git/hooks/sample/<all the sample hook files>
> .git/hooks/topgit/pro-commit
>
> ?
>
> Then you can actually link in your own personal check script directories
> easily *and* you can add them to the repository eg by using
> comitted-repo-hooks instead of .git/hooks
> ?
> This way you could provide different hook directories for different
> platforms and all you have to do is enabling them by adding the path to
> .git/list-of-hook-directories ?
>
> I guess the second approach of defining kind of overlays is better
> because it doesn't interfer with the existiing scheme?
> Maybe it should be implemented as git config option instead of a file
> containing the list of directories?
>
> The hook direcotry list apporach is better because you've more control
> about order of execution..
>
> Thoughts?
>
> Marc Weber
^ permalink raw reply
* Re: document ext3 requirements
From: Duane Griffin @ 2009-01-03 23:38 UTC (permalink / raw)
To: Martin MOKREJŠ
Cc: Pavel Machek, kernel list, Andrew Morton, tytso, mtk.manpages,
rdunlap, linux-doc
In-Reply-To: <495FEE66.9080903@ribosome.natur.cuni.cz>
2009/1/3 Martin MOKREJŠ <mmokrejs@ribosome.natur.cuni.cz>:
> Hmm, so if my dual-boot machine does not shutdown correctly and I boot
> accidentally in M$ Win where I use ext2 IFS driver and modify some
> stuff on the ext3 drive, after a while reboot to linux and the journal
> get re-played ... Mmm ...
You *really* wouldn't want to be doing that.
The other scenario that people have reported trouble with is
suspending the system, booting a live CD which "read-only" mounts the
filesystem (and replays the journal), then resuming.
Cheers,
Duane.
--
"I never could learn to drink that blood and call it wine" - Bob Dylan
^ permalink raw reply
* Re: Bug/Warning report for the week of January 3rd, 2009
From: Robert Hancock @ 2009-01-03 23:40 UTC (permalink / raw)
To: Arjan van de Ven
Cc: linux-kernel, torvalds, akpm, x86, netdev, tytso, eric, airlied
In-Reply-To: <20090103140332.74f39ade@infradead.org>
Arjan van de Ven wrote:
> Rank 2: mtrr_trim_uncached_memory (warning)
> Reported 420 times (9816 total reports)
> BIOS bug (often in VMWare) where the MTRR's are set up incorrectly or not at all
> This warning was last seen in version 2.6.28, and first seen in 2.6.24.
> More info: http://www.kerneloops.org/searchweek.php?search=mtrr_trim_uncached_memory
It would be useful if this warning dumped out some DMI BIOS information
or something, so we could see what systems/boards this was commonly
happening with..
^ permalink raw reply
* Re: [PATCH 1/2] New Control Plugin - arcam-av
From: Robin H. Johnson @ 2009-01-03 23:35 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <200901032056.35982.linux@dadeos.co.uk>
[-- Attachment #1.1: Type: text/plain, Size: 418 bytes --]
On Sat, Jan 03, 2009 at 08:56:35PM +0000, Peter Stokes wrote:
> Signed-off-by: Peter Stokes <linux@dadeos.co.uk>
Please exclude the changes to Makefile.in in patches 1 and 2.
Makefile.am is the only ones that are needed since Makefile.in is
generated.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #1.2: Type: application/pgp-signature, Size: 329 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [RFC, PATCH] kernel/rcu: add kfree_rcu
From: Paul E. McKenney @ 2009-01-03 23:46 UTC (permalink / raw)
To: Manfred Spraul; +Cc: linux-kernel, akpm, laijs
In-Reply-To: <495F7D5C.3060905@colorfullife.com>
On Sat, Jan 03, 2009 at 03:59:40PM +0100, Manfred Spraul wrote:
> Paul E. McKenney wrote:
>> I would suggest instead using the bottom bit to differentiate between
>> these two cases, especially given that your approach makes it impossible
>> for callback processing to notice a NULL function pointer. In addition,
>> this approach would allow different types of allocators to be specified
>> should this later prove to be helpful. You should not have to shift the
>> offset because the rcu_head offset should always be a multiple of four
>> (or eight on 64-bit architectures).
>>
> We must be careful: rcu_head might be always aligned, but are function
> pointers always aligned?
> The x86 hardware allows arbitrary function pointers, I'm not sure what gcc
> would do if '--falign-functions=0' is used.
> Are there other codepaths that assume that the lowest bit of a function
> pointer is never set?
Good point. I guess that we will have to worry about expandability when
and if the need arises. I see a couple of ways of doing it, but they
are pretty ugly...
>> And we really are running into bugs that are detected by RCU's seeing a
>> null function pointer in the rcu_head structure at callback-invocation
>> time. So, whatever encoding you choose, please leave a function-pointer
>> value of zero as an invalid value!
>>
> Ok.
>
>>> --- a/kernel/rcutree.c
>>> +++ b/kernel/rcutree.c
>>> @@ -901,7 +901,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
>>> while (list) {
>>> next = list->next;
>>> prefetch(next);
>>> - list->func(list);
>>> + rcu_docallback(list);
>>>
>>
>> Good, you got all three of them! ;-)
>>
>>
> The patch was tested against rcutree ;-)
;-)
Thanx, Paul
^ permalink raw reply
* Re: [JGIT PATCH 13/13] Add basic git daemon support to publish receive-pack
From: Robin Rosenberg @ 2009-01-03 23:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1229992043-1053-14-git-send-email-spearce@spearce.org>
tisdag 23 december 2008 01:27:23 skrev Shawn O. Pearce:
> + private static final Pattern SAFE_REPOSITORY_NAME = Pattern
> + .compile("^[A-Za-z][A-Za-z0-9/_ -]+(\\.git)?$");
This restriction is too strict. Wouldn't any path not containing ".." be valid? In particular this did not work with my "EGIT.contrib" repo. I
have a lot of repos with names llike "name.purpose". Just adding
'.' to the character set isn't really enough.
-- robin
^ permalink raw reply
* Re: document ext3 requirements
From: Martin MOKREJŠ @ 2009-01-03 23:50 UTC (permalink / raw)
To: Duane Griffin
Cc: Pavel Machek, kernel list, Andrew Morton, tytso, mtk.manpages,
rdunlap, linux-doc
In-Reply-To: <e9e943910901031538m24ff9616na2aaf3a57f161655@mail.gmail.com>
Duane Griffin wrote:
> 2009/1/3 Martin MOKREJŠ <mmokrejs@ribosome.natur.cuni.cz>:
>> Hmm, so if my dual-boot machine does not shutdown correctly and I boot
>> accidentally in M$ Win where I use ext2 IFS driver and modify some
>> stuff on the ext3 drive, after a while reboot to linux and the journal
>> get re-played ... Mmm ...
>
> You *really* wouldn't want to be doing that.
>
> The other scenario that people have reported trouble with is
> suspending the system, booting a live CD which "read-only" mounts the
> filesystem (and replays the journal), then resuming.
Why does not "mount -ro" die when it would have to replay the journal
with a message that user must run fsck.ext3 in order to be able to mount
it albeit read-only? Still I would prefer having an extra switch to
force mount RO while not touching the journal for disk forensics.
I think that would also prevent the cases when a LiveCD/rescue distribution
would not mount+replay it automagically but user would really have to
provide the switch to the command. I am really not using the recovery
boot cd to touch my partitions in some cases unwillingly.
Sure that does not prevent my case when I let ext2 IFS writing onto
my ext3 partition. Actually, couldn't the driver at least warn me
the journal log is non-empty (am just a user, sorry, cannot check
myself the code at www.fs-driver.org if it could do at least this
although it does not understand ext3). ;-)
Martin
^ permalink raw reply
* Re: atomics: document that linux expects certain atomic behaviour from unsigned long
From: Robert Hancock @ 2009-01-03 23:53 UTC (permalink / raw)
To: Pavel Machek
Cc: Alan Cox, kernel list, Andrew Morton, mtk.manpages, rdunlap,
linux-doc
In-Reply-To: <20090103205628.GE1666@elf.ucw.cz>
Pavel Machek wrote:
> On Sat 2009-01-03 20:30:44, Alan Cox wrote:
>>> If it is okay and linux relies on it, it should be documented.
>>>
>>> If it is not okay, I guess we should document it, too -- it seems to
>>> be common mistake.
>> A lot of old code did it knowing it was under the BKL, outside of the BKL
>> its a very bad idea. There were lots of them in the tty layer and I don't
>> doubt there are some left I missed too 8(
>
> I have seen this in new code (some LED driver last time), definitely
> no BKL.
>
> Is there concrete architecture where it breaks? I'd expect i386/x86-64
> to be safe, and pretty much everyone to be safe as long as that long
> is aligned.... or that was the result of arch-maintainers
> discussion...
>
> I'd really like to document if it is right or not, so that I can point
> people to documentation...
> Pavel
If you look at the atomic implementation on x86 all it does is assign
and read the internal int variable directly for atomic_set and
atomic_read, so I suppose it would be OK to just use a normal variable
in that case.. but then there's no performance hit so you might as well
use atomic_t anyway. On some architectures like arm and sparc there is
some magic involved in atomic_set and/or atomic_read (but those may just
be to guard against other concurrent atomic ops, I'm not sure).
Certainly unless the code is really performance critical there is no
point messing around, just use an atomic if it needs to be accessed
without locking. Note that memory barriers may be an issue as well..
^ permalink raw reply
* Re: [PATCH] Fix race in ring_buffer_consume(): Replace ring_buffer_consume and ring_buffer_peek with ring_buffer_get_event
From: Steven Rostedt @ 2009-01-03 23:55 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Indan Zupancic, Ingo Molnar, linux-kernel
In-Reply-To: <20090102220818.GD17240@elte.hu>
On Fri, 2009-01-02 at 23:08 +0100, Ingo Molnar wrote:
> * Indan Zupancic <indan@nul.nu> wrote:
>
> > On Mon, December 29, 2008 13:24, Ingo Molnar wrote:
> > >
> > > * Indan Zupancic <indan@nul.nu> wrote:
> > >
> > >> Original mail was mangled, patch resent via git.
> > >>
> > >> Signed-off-by: Indan Zupancic <indan@nul.nu>
> > >> ---
> > >> include/linux/ring_buffer.h | 4 +---
> > >> kernel/trace/ring_buffer.c | 39
> > >> ++++++++-------------------------------
> > >> kernel/trace/trace.c | 15 ++++++++-------
> > >> kernel/trace/trace_selftest.c | 2 +-
> > >> 4 files changed, 18 insertions(+), 42 deletions(-)
> > >
> > > there's been a number of updates here - could you please do a patch
> > > against tip/master:
> > >
> > > http://people.redhat.com/mingo/tip.git/README
> >
> > Thanks for that readme, now I discovered git remote, which is not
> > mentioned often enough for some reason.
> >
> > A lot changed indeed, most importantly the race that I hit is
> > fixed in tip by improved locking. Replace ring_buffer_consume()
> > and ring_buffer_peek() with ring_buffer_get_event() or not is
> > just a matter of taste now. Are you still interested in such a
> > patch?
>
> the code gets simpler and more readable, so why not? Steve, any
> objections?
I'd like to look closer at this code on Monday.
Thanks,
-- Steve
^ permalink raw reply
* [Qemu-devel] Who is mips maintainer after Thiemo?
From: Rob Landley @ 2009-01-03 23:39 UTC (permalink / raw)
To: qemu-devel
According to http://lwn.net/Articles/313092/ Thiemo Seufer was killed in a car
crash December 26th.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.