* Re: Trivial connlimit and IPMARK patch for 2.6.16
From: Harald Welte @ 2006-04-05 15:26 UTC (permalink / raw)
To: Grzegorz Janoszka; +Cc: netfilter-devel, Patrick McHardy
In-Reply-To: <Pine.GSO.4.63.0604040002220.15645@galaxy.agh.edu.pl>
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
On Tue, Apr 04, 2006 at 12:09:52AM +0200, Grzegorz Janoszka wrote:
>
> Hello,
>
> Due to move of some targets from iptables to xtables, some patches turned to "not applyable", becouse
> their Makefile.ladd files
> tried to add iptables entries just after a target, that had been moved from iptables to xtables.
>
> Attached patch solves this problem, it only modifies Makefile.ladd files of connlimit and IPMARK. The
> patch is to patch-o-matic-ng-20060401 but it should apply clearly on any latest pom-ng.
I'm not really in the mood of manually adding such patches to svn.
I'm not really sure on the future of patch-o-matic as a whole. At least
I haven't really used any of the patches from there or updated anything
or tested whether it applies for at least half a year.
So unless somebody actually wants to become patch-o-matic maintainer
(yes, we once had somebody for that job), I think it's going to die.
Patrick, any news on that 'patch o matic remote repositories' idea?
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Multiple programs for QUEUE target
From: Harald Welte @ 2006-04-05 15:24 UTC (permalink / raw)
To: David Vogt; +Cc: netfilter-devel
In-Reply-To: <859616420604040702g1e74bcacr2115fb36e0e7298e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
On Tue, Apr 04, 2006 at 04:02:41PM +0200, David Vogt wrote:
> 2006/4/4, David Vogt <beunlovable@gmail.com>:
> > I am sure I read something about a "dispachter"-like program,
> > but I can't find it.
>
> Of course I found it right after posting to the list. ipqmpd it is
> called, however, it requires rewriting the program to some extend.
> Since this is not possible for the closed source program, any advice
> on how a solution to that problem might look like are highly
> appreciated.
Please don't use any of that old 'crap' (I'm the author, so I can call
it that). These days, you use NFQUEUE, nf_queue, nfnetlink_queue,
libnetfilter_queue, and you get up to 65535 distinct queues for
different userespace processes.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] SPARC iommu mapping
From: Joerg Platte @ 2006-04-05 15:23 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <200604042127.55487.lists@naasa.net>
Am Dienstag, 4. April 2006 21:27 schrieb Joerg Platte:
Hi!
> To find this problem, I enabled debugging in the esp.c file and printed the
> mapped address (after iommu mapping). In some cases the mapped address is
> zero:
> ESP: DMA address 0beb8000
> ESP: DMA address 00000000
I didn't find a manual of the SBUS IOMMU. But if I understand the contents of
newer implementations of an IOMMU, each entry in this MMU table has a valid
bit. And therefore, a 0 entry is invalid. But the current implementation of
qemu's IOMMU does not check for a valid bit. Where can I find more
information on this topic? And is a besser IOMMU currently in development?
regards,
Jörg
^ permalink raw reply
* Re: [PATCH] ip_conntrack section mismatch warning fix
From: Harald Welte @ 2006-04-05 15:23 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, Stephen Hemminger
In-Reply-To: <4433D496.2090706@trash.net>
[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]
On Wed, Apr 05, 2006 at 04:30:46PM +0200, Patrick McHardy wrote:
> Stephen Hemminger wrote:
> > This is a bit of a hack. It eliminates the section mismatch warning from
> > latest linker. What happens is the init_or_cleanup code gets called
> > from cleanup() hook and the linker thinks it will reference __initdata
> > because of it's limited static analysis. By asking compiler to
> > inline, it can eliminate that dead code. It does the __init text
> > section to grow, but then the space can be reclaimed.
>
> I think this might still fail without forced inlining. Our init
> functions look like crap anyway, and the reason mostly seems to
> be mass-registration of hooks, so I guess I'll clean that up
> with a small helper function and then just split them.
still I actually think of the shared init/cleanup functions as a big
feature rather than something that needs to be 'cleaned up'.
I'm obviously not opposing something like nf_register_hook_array(), but
that's a different issue.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Throttling NAT interface
From: Casey Scott @ 2006-04-05 15:22 UTC (permalink / raw)
To: netfilter
The gist of what I need to do is restrict the rate of
off-network traffic coming in through a host. The host
is providing basic NAT to an internal network. I have
gotten pretty close to what I need to do with iptables
and tc. The problem is that when an interface is throttle
with tc, the source of the traffic doesn't matter. I don't
want to throttle local traffic, just traffic coming through
the machine from a WAN. The next step was to add another
NIC to the machine. Something like this:
eth0: <local IP1>
eth1: <WAN IP>
eth2: <local IP2>
The problem is that even if traffic destined to be routed
off network comes into eth2, which is throttle via tc, the
return traffic comes back through eth0. Since tc (tbf filter)
just controls the transmitting of an interface, I need to
force the NAT traffic to use eth2. Traffic that is meant to
stay local can use eth0. Is possible to do something like this?
How can I this host to only eth2 for NAT even though both eth0
and eth2 are in the same network? eth0 is not throttled, which
is why local traffic needs to use it.
TIA,
Casey
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Al Viro @ 2006-04-05 15:21 UTC (permalink / raw)
To: Sergey Vlasov
Cc: gregkh, Justin Forbes, Zwane Mwaikambo, Theodore Ts'o,
Randy Dunlap, Dave Jones, Chuck Wolber, torvalds, akpm, alan,
linux-kernel, stable, Jon Smirl
In-Reply-To: <20060405190928.17b9ba6a.vsu@altlinux.ru>
On Wed, Apr 05, 2006 at 07:09:28PM +0400, Sergey Vlasov wrote:
> This will break the "color_map" sysfs file for framebuffers -
> drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
> for a colormap with 256 entries. In fact, the original patch which
> changed PAGE_SIZE - 1 to PAGE_SIZE:
... cheerfully assuming that nobody assumes NUL-termination and
everyone (sysfs patch writers!) certainly uses the length argument.
Fscking brilliant, that.
Are you willing to audit all sysfs ->show() in the kernel? Original
author of that turd had not been.
FWIW, "color_map" is a blatant abuse of interface. Doesn't get
any more borderline...
^ permalink raw reply
* Re: Can't mount /dev/md0 after stopping a synchronization
From: Troels Bang Jensen @ 2006-04-05 15:21 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <c79e949d0604042045w2fb901c2rfb4c00984f6b8761@mail.gmail.com>
This isn't quite what you asked about, but the rootraiddoc97 document is
kinda obsolete by now
-Debian Sarge has a new partitioner which can set up pretty advanced
RAID configurations when installing. Just create RAID auto partitions on
the disks and then create the arrays afterwards in the partitioner -
it's far easier, and I've set up quite a few boot-on-RAID1 systems that way.
/Troels
Mike Garey wrote:
> Just wanted to add a few more details/questions to my previous post..
>
> In case I provided too much information in my previous email, here's a
> condensed version:
>
> 1) got to "step 6.2 Add the first-disk to our existing RAID device" of
> the rootraiddoc walkthrough
> 2) issued command "mdadm --add /dev/md0 /dev/hda1"
> 3) after getting terrible throughput, decided to stop the
> synchronization process and reboot
> 4) failed to reboot from /dev/md0 (hdc1)
> 5) hda1 is now hosed, hdc1 contains a complete working copy of the
> previous contents of /dev/hda1, but I'm unable to boot from it
> ("ALERT! /dev/md0 does not exist" message)
> 6) re-installed debian onto hda1 and rebooted from it.
>
> Now, it seems as though I'm sort of back at "step 3.3 Create RAID
> device". I've tried to do the following while booted from my clean
> debian install on /dev/hda1:
>
> mkdir /mnt/md0
> mount /dev/md0 /mnt/md0
>
> but I get the message "mount: you must specify the filesystem type",
> because I guess the system has no idea what /dev/md0 is. So then I
> tried the following (possibly risky?) command:
>
> mdadm --create /dev/md0 --level=1 --raid-disks=2 --spare-devices 0
> missing /dev/hdc1
>
> but I get the message:
>
> mdadm: /dev/hdc1 appears to contain an ext2fs file system
> size=158577472K mtime=Tue Apr 4 18:21:09 2006
> mdadm: /dev/hdc1 appears to be part of a raid array:
> level=1 devices=2 ctime=Mon Apr 3 13:41:33 2006
> Continue creating array? n
> mdadm: create aborted
>
> It seems from the above message that mdadm --create would destroy all
> the data on /dev/hdc1 (someone correct me if I'm wrong), rather than
> simply creating /dev/md0. If this is the case, should I be using
> mdadm --assemble instead? (but if so, I need to assemble to a
> pre-existing md device, in which case I don't have one) What I'd like
> to do is be able to mount /dev/hdc1 as /dev/md0 (as in "step 4.2 Mount
> your RAID device."), and then hopefully be able to boot off of it, but
> right now I'm confused about how to create /dev/md0 without destroying
> any of my information on either /dev/hda1 or /dev/hdc1 (of course,
> after the reboot, I don't mind destroying /dev/hda1).
>
> the other alternative is of course to zero the superblocks on
> /dev/hdc1, reboot from it as a normal drive, and then follow the
> walkthrough from the beginning, but this time starting with /dev/hdc1
> as the master drive. I'd like to avoid this if possible, since I'd
> really like to find out why I can't boot from /dev/md0 (hdc1), since
> if this was not a test, and /dev/hda1 really did fail, I'd be in a
> mess. So I'd prefer to know how to recover from this, since it seems
> that the position I'm in right now is essentiallly the same scenario
> as if /dev/hda1 had failed, in which case I'd like to be prepared.
>
> If anyone can make heads or tails of what I'm talking about, I would
> greatly appreciate any information or suggestions. Thanks in advance,
>
> Mike
>
> P.S. output of mdadm --examine is given below (output is the same for
> /dev/hda1 and /dev/hdc1)
>
> Magic : a92b4efc
> Version : 00.90.03
> UUID : f1ab0f6d:6c5c4bf6:228dec79:3aa3582f
> Creation Time : Mon Apr 3 13:41:33 2006
> Raid Level : raid1
> Raid Devices : 2
> Total Devices : 2
> Preferred Minor : 0
>
> Update Time : Tue Apr 4 09:37:10 2006
> State : clean
> Active Devices : 1
> Working Devices : 2
> Failed Devices : 0
> Spare Devices : 1
> Checksum : f63c0eb5 - correct
> Events : 0.19314
>
>
> Number Major Minor RaidDevice State
> this 1 22 1 1 active sync /dev/hdc1
>
> 0 0 0 0 0 removed
> 1 1 22 1 1 active sync /dev/hdc1
> 2 2 3 1 2 spare /dev/hda1
>
>
>
>> I'm in the process of setting up a software RAID level 1 on debian
>> testing with two 160 gig drives on an Asus P4P800 motherboard with
>> Intel Pentium 4 CPU 3.00GHz and 512 megs of RAM. I've been following
>> the instructions in /usr/share/doc/mdadm/rootraiddoc97.html, but after
>> rebooting to /dev/hdc1 (/dev/md0) and issuing the command "mdadm --add
>> /dev/md0 /dev/hda1", I was only getting 1636K/sec for the
>> synchronization, which was _way_ too slow (I forgot I had left a CDROM
>> drive on the secondary IDE channel, so /dev/hdc1 was running at UDMA2,
>> plus, I was using a 40 conductor cable instead of 80). So I decided
>> to reboot the system and cancel the synchronization, thus destroying
>> everything on /dev/hda1 (but this didn't seem like an issue, since I
>> was able to boot from /dev/md0 aka /dev/hdc1).
>>
>> So after stopping the sync process and rebooting, I was unable to boot
>> from hdc1 because I had forgotten to copy over my initrd with md/raid1
>> modules from /dev/hda1 to /dev/hdc1, and of course now /dev/hda1 is
>> destroyed, so I can't use the initrd-RAID that was previously on there
>> (and the initrd-RAID never existed on /dev/hdc1, since I created it on
>> /dev/hda1 _after_ I had issued the "mount /dev/md0 /mnt/md0; cp -axu /
>> /mnt/md0" commands - don't ask why). So when I rebooted, I didn't
>> have md/raid1 support, and so /dev/md0 couldn't mount.. I ended up
>> building a new initrd with md/raid1 on another debian box, then
>> copying them to /dev/hdc1. I've now tried installing grub on
>> /dev/hdc, disconnected /dev/hda, and attempted to boot. I now get the
>> following message:
>>
>> md: md driver 0.90.3 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27
>> md: bitmap version 4.39
>> md: raid1 personality registered as nr3
>> .
>> .
>> Begin: Mounting root file system...
>> Begin: Running /scripts/local-top
>> Done.
>> ALERT! /dev/md0 does not exist. Dropping to a shell!
>>
>> At which point I get dropped into busybox.. One thing I notice is
>> that although it shows the md module being loaded, it doesn't really
>> say anything about configuring/adding any RAID disks (which is used to
>> say, back when I had first booted into /dev/md0 (hdc1) before killing
>> /dev/hda1). So now apparently /dev/md0 no longer exists, and I have
>> no idea how to create it.
>>
>> In fstab on /dev/hcd1, I have:
>>
>> /dev/md0 / ext3 defaults 0 0
>>
>> and in /boot/grub/menu.lst I have:
>>
>> title Debian GNU/Linux, kernel 2.6.15-486 RAID
>> root (hd0,0)
>> kernel /boot/vmlinuz-2.6.15-486 root=3D/dev/md0 ro
>> initrd /boot/initrd.img-2.6.15-486-RAID
>> savedefault
>> boot
>>
>> Now, /dev/md0 was originally created by using:
>>
>> mdadm --create /dev/md0 --level=3D1 --raid-disks=3D2 missing /dev/hdc1
>>
>> can anybody tell me why /dev/md0 is no longer available on /dev/hdc1,
>> and if possible how to recreate it?
>>
>> I should mention that after I cancelled the synchronization process,
>> and was unable to reboot into /dev/hdc1, I then mounted /dev/hdc1
>> through busybox, changed the Type of the disk from FD (linux raid) to
>> 83 (linux), modified /etc/fstab and /boot/grub/menu.lst so it pointed
>> to /dev/hdc1 instead of /dev/md0. I tried rebooting after changing
>> these options, and it gave me a message saying "Failed to mount root
>> file system" or something to that effect. Could changing the Type of
>> the disk or mounting /dev/hdc1 have caused /dev/md0 to become
>> corrupted/deleted?
>>
>> If anybody has the time to read through my message
>> and give me some advice, I would very much appreciate it. Thanks,
>>
>> Mike
>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* Re: H.323 conntrack/NAT helper update for 2.6.17-rc1
From: Harald Welte @ 2006-04-05 15:21 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <BAY109-DAV15AA944ABA789908271E35B3CB0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Tue, Apr 04, 2006 at 08:29:57PM -0400, Jing Min Zhao wrote:
> Hi, Patrick,
>
> This patch is to update 2.6.17-rc1 to the latest state. It includes following changes that are not in
> 2.6.17-rc1:
just as a minor note: Please attach patches in plaintext, so people can
read them in their mail readers rather than having to save, extract,
read, delete them (which is time consuming).
Thanks!
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: bad blocks on disk. Which files are damaged?
From: Vladimir V. Saveliev @ 2006-04-05 15:20 UTC (permalink / raw)
To: el jeskynar; +Cc: reiserfs-list
In-Reply-To: <BAY24-F14A8F21FB4DCCAFF18E792DCCB0@phx.gbl>
Hello
On Wed, 2006-04-05 at 15:12 +0000, el jeskynar wrote:
> Hello,
>
> I never did see an answer to the original poster's question:
>
> "I'd really like to find out which files on the Reiser3.6 FS on the
> defective
> disk are probably damaged."
>
> The bad-block-handling document doesn't seem to cover this,
> how can one find out the names of files containing bad blocks?
>
I guess that such files will get listed by the below command:
find -type f -exec cat {} > /dev/null \;
> I've seen mention of icheck and ncheck tools but 1) I can't find
> them, and 2) I presume they would not work with reiserfs unless
> specifically written so.
>
> Thank you!
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
^ permalink raw reply
* register/unregister SATA drive
From: Dieter Stüken @ 2006-04-05 15:20 UTC (permalink / raw)
To: linux-ide
is it possible to unregister a single SATA port and to detach the disk?
how do I inform the kernel to rescan for a newly attached drive on that
port?
Dieter.
^ permalink raw reply
* Re: Update: Patch-o-matic cleanup
From: Carl-Daniel Hailfinger @ 2006-04-05 15:20 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist
In-Reply-To: <4433CA75.9040607@trash.net>
Hi Patrick,
Patrick McHardy schrieb:
>
> After receiving multiple "please keep this patch" mails, it seems I
> started the wrong way.
>
> Removing old patches is part of a greater plan to reduce the content of
> pom to only those things the netfilter team has an interest in
> maintaining, and most of these things will be merged in not too long
> time. _All_ other patches will be removed and the "runme" tool will
> be enhanced by an apt-get like mechanism to download patches from
> external sources[...]
But why keep a few patches in pom and throw out the rest? Wouldn't it
make sense to reduce pom to a simple script and throw out all patches?
The few patches maintained by the netfilter team could be moved to a
separate pom-hotfix package and be automatically downloaded by the
pom script.
OTOH, having a pom-ng that can be applied without a network connection
was very helpful for me in the past. So if you are really going to
discontinue pom-ng as is, I offer to take over maintenance. Fetching
the different packages from locations in a list and assembling them
into one pom-full package automatically can't be that difficult.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
* Re: [RFC] Auto rebind PCI devices
From: Mark Williamson @ 2006-04-05 15:18 UTC (permalink / raw)
To: xen-devel; +Cc: hap9
In-Reply-To: <20060404190935.GB1221@granada.merseine.nu>
> > * If the device specificed in the config is bound *and* pci-force-rebind
> > is set, then unbind it from the existing driver and rebind it to pciback,
> > then start the domain.
>
> That sounds awkward. What's the use case you see in mind from stealing
> devices from a domain while it's running?
To clarify my thinking on this a little more: I think it would be good to be
able to move PCI devices between domains in a reasonably straightforward way.
This would be something like the PCI hotplug for IBM's dynamic LPAR, which is
already supported by Linux.
The eventual goal being that you can reassign PCI devices "hotplug-style" (it
would look like a hotplug to the pcifront kernel) at runtime, with the user
interface providing appropriate safety checks / "do you really want this?"
dialogs, according to the level of confidence of the user.
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
^ permalink raw reply
* Re: [uml-devel] find_iomem hangs up
From: Jeff Dike @ 2006-04-05 14:19 UTC (permalink / raw)
To: Victor V. Vengerov; +Cc: user-mode-linux-devel
In-Reply-To: <4433958F.3090200@oktetlabs.ru>
On Wed, Apr 05, 2006 at 02:01:51PM +0400, Victor V. Vengerov wrote:
> When I've build uml with mmapper driver in, and attempted to pass
> something like iomem=xxx,yyy in command line, guest kernel hang up on
> boot. This is because of error in find_iomem - see patch below.
Applied, thanks.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* [PATCH] kexec: update MAINTAINERS
From: Randy.Dunlap @ 2006-04-05 15:19 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: horms, linux-kernel, fastboot, akpm, torvalds
In-Reply-To: <m1mzf0in0n.fsf@ebiederm.dsl.xmission.com>
From: Randy Dunlap <rdunlap@xenotime.net>
Eric is the kexec maintainer.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
MAINTAINERS | 2 --
1 files changed, 2 deletions(-)
--- linux-2617-rc1.orig/MAINTAINERS
+++ linux-2617-rc1/MAINTAINERS
@@ -1556,9 +1556,7 @@ S: Maintained
KEXEC
P: Eric Biederman
-P: Randy Dunlap
M: ebiederm@xmission.com
-M: rdunlap@xenotime.net
W: http://www.xmission.com/~ebiederm/files/kexec/
L: linux-kernel@vger.kernel.org
L: fastboot@osdl.org
---
^ permalink raw reply
* Re: bad blocks on disk. Which files are damaged?
From: el jeskynar @ 2006-04-05 15:12 UTC (permalink / raw)
To: reiserfs-list
Hello,
I never did see an answer to the original poster's question:
"I'd really like to find out which files on the Reiser3.6 FS on the
defective
disk are probably damaged."
The bad-block-handling document doesn't seem to cover this,
how can one find out the names of files containing bad blocks?
I've seen mention of icheck and ncheck tools but 1) I can't find
them, and 2) I presume they would not work with reiserfs unless
specifically written so.
Thank you!
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Jakub Narebski @ 2006-04-05 15:11 UTC (permalink / raw)
To: git
In-Reply-To: <7v3bgs4exz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> It _might_ make sense to adopt a well-defined binary patch
> format (or if there is no prior art, introduce our own) and
> support that format with both git-diff-* brothers and git-apply,
> but that would be a bit longer term project.
bsdiff? http://www.daemonology.net/bsdiff/
EDelta? http://www.diku.dk/~jacobg/edelta/
Xdelta? http://xdelta.blogspot.com/
IIRC bsdiff is used by Firefox to distribute binary software updates.
Xdelta is generic (not optimized for binaries like bsdiff and edelta), but
supposedly offers worse compression (bigger diffs).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* SuSE 10.0 and it's RPM 4.1.1??
From: Hal MacArgle @ 2006-04-05 15:10 UTC (permalink / raw)
To: linux-newbie
Greetings: A Slackware junkie all my Linux life, I'm just now
"playing" with other distributions that use RPM..
At first I thought, piece of cake, invoking rpm -i package.rpm;
slick..
That didn't last, when I tried installing a package that didn't play
ball, and opened Pandora's box of queries.. Man rpm shed some light,
what I understood, so I pulled a book I had covering Red Hat 6.2 -
rather old, but just maybe??
rpm -i package.rpm - returns "warning: package.rpm: V3 DSA signature:
NOKEY, key ID [octet of characters]
error: Failed dependencies: (with a list of no less than 15 of them
reporting the exact library needed...)
First off, I didn't know what V3 DSA meant, but the missing
dependencies are fairly normal these days.. I had some work ahead of
me but the RedHat book said to use rpm -q --redhatprovides
<library.so.X> and it would list the base package needed.. This is
not RedHat, of course, but there is a --provides flag that didn't
return anything except that the package was missing.. I tried that
entering a library that's either in /lib or /usr/lib, and it returned
"Package not installed." I'm presuming this has been changed for, at
least, libraries.. Or--is it the NOKEY thingy?? Stumped!!
BTW the subject package was fetched from rpm.pbone.net, whereas the
rpm's installed previous to that were ones in the SuSE distribution
package.. That has to have a lot to do with it, IMHO... <grin>
Is there a tutorial that explains this better than the man?? TIA.
--
Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Sergey Vlasov @ 2006-04-05 15:09 UTC (permalink / raw)
To: gregkh
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, torvalds, akpm, alan,
Greg Kroah-Hartman, linux-kernel, stable, Jon Smirl
In-Reply-To: <20060404235947.GD27049@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]
On Tue, 4 Apr 2006 16:59:47 -0700 gregkh@suse.de wrote:
> No one should be writing a PAGE_SIZE worth of data to a normal sysfs
> file, so properly terminate the buffer.
>
> Thanks to Al Viro for pointing out my stupidity here.
>
> CVE-2006-1055 has been assigned for this.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
> ---
> fs/sysfs/file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.16.1.orig/fs/sysfs/file.c
> +++ linux-2.6.16.1/fs/sysfs/file.c
> @@ -183,7 +183,7 @@ fill_write_buffer(struct sysfs_buffer *
> return -ENOMEM;
>
> if (count >= PAGE_SIZE)
> - count = PAGE_SIZE;
> + count = PAGE_SIZE - 1;
> error = copy_from_user(buffer->page,buf,count);
> buffer->needs_read_fill = 1;
> return error ? -EFAULT : count;
This will break the "color_map" sysfs file for framebuffers -
drivers/video/fbsysfs.c:store_cmap() expects to get exactly 4096 bytes
for a colormap with 256 entries. In fact, the original patch which
changed PAGE_SIZE - 1 to PAGE_SIZE:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d9d27fb651a7c95a46f276bacb4329db47470a6
was done exactly for use with that "color_map" file.
This patch also does not completely guarantee that the buffer will be
null-terminated. A program may first call read() on the sysfs file,
which will allocate buffer->page and invoke ->show to fill that page;
then subsequent write() on the same file will reuse buffer->page. To
get really bad results, you need to have ->store which assumes
null-terminated buffer together with ->show which writes to the last
byte of the page (which is probably rare, but show_cmap() does exactly
that).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Here is the tcp-zero-copy patch for kernel 2.6.12-6 .
From: Jeff Garzik @ 2006-04-05 15:05 UTC (permalink / raw)
To: yzy; +Cc: linux-kernel, eeb, green
In-Reply-To: <44336CC0.6030206@clusterfs.com>
yzy wrote:
> Hello linux-kernel:
>
> I do some work on tcp-zero-copy for kernel 2.6.12-6 ( vanilla ) , Here
> is the patch . Please review and discussion it .
>
> The patch modify mainly these files below :
> (1) include/linux/skbuff.h : add a zccd_t struct , it include the
> zero-copy's callback function pointer and reference count.
> (2)include/net/tcp.h : add a new function tcp_sendpage_zccd( ) . It
> was used as send a memory page to TCP/IP stack.
> (3)net/core/dev.c (4)net/core/skbuff.c : process the initial ,refcount
> and release of zccd information.
> (5)net/ipv4/tcp.c : call the tcp_sendpage_zccd() function to send a
> memory page.
1) Why, we already have zero-copy?
2) Please send to netdev@vger.kernel.org, which is where the people who
maintain this code live.
Jeff
^ permalink raw reply
* Re: VPN module
From: Joshua Brindle @ 2006-04-05 15:04 UTC (permalink / raw)
To: Christopher J. PeBenito; +Cc: Erich Schubert, SE Linux
In-Reply-To: <1144248600.12875.2.camel@sgc.columbia.tresys.com>
Christopher J. PeBenito wrote:
> On Wed, 2006-04-05 at 13:59 +0200, Erich Schubert wrote:
>> Hi,
>> I'll probably write a OpenVPN module sometime soon.
>> We already have a "vpn" module, but that is only for the vpnc client so
>> far.
>> Should I
>> - try to make a single module for both (I consider that a bad idea,
>> since vpnc is a client only for cisco VPNs, whereas OpenVPN can be used
>> as a full-blown VPN server and is much more flexible)
>> - rename the vpn policy to vpnc and make a new "openvpn" module?
>
> Creating openvpn will be fine, but the vpn module has to stay as is,
> because we can't rename modules, because it causes upgrade issues. For
> example, if you have a vpn module inserted, and you try to insert vpnc
> module, it fails because of duplicate symbols. Perhaps we need support
> in modules for one module to deprecate another, so if you insert the
> vpnc module, libsemanage automatically removes vpn as part of the
> transaction.
>
I think this is a package manager issue, not a module issue. Package
managers already know how to handle complex relationships and I don't
know why we would reproduce that in libsemanage.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [Xenomai-help] problems building xenomai 2.1 for ppc
From: Gilles Chanteperdrix @ 2006-04-05 15:04 UTC (permalink / raw)
To: Landau, Bracha; +Cc: xenomai
In-Reply-To: <02AA386EB831044F8537A696BA785C78A664EF@ILEX5.IL.NDS.COM>
Landau, Bracha wrote:
> I'm trying to build xenomai 2.1 for an 8272 architecture using kernel 2.6.14.
> I've successfully put in the adeos patch.
> Here are the problems I've encountered.
>
> 1) When doing ./scripts/prepare-kernel.sh I get an error that it can't find the file /include/asm-powerpc/ipipe.h.
> I copied the file ipipe.h from /include/asm-ppc and reran prepare-kernel.sh with no errors.
For a quick step by step install guide of Xenomai with Denx ELDK, see also:
https://mail.gna.org/public/xenomai-help/2006-04/msg00059.html
--
Gilles Chanteperdrix.
^ permalink raw reply
* Re: [libnetfilter_queue]
From: David Vogt @ 2006-04-05 15:03 UTC (permalink / raw)
To: Eric Leblond; +Cc: netfilter@lists.netfilter.org
In-Reply-To: <1144248241.4406.11.camel@localhost.localdomain>
2006/4/5, Eric Leblond <eric@inl.fr>:
> Le mercredi 05 avril 2006 à 14:56 +0200, David Vogt a écrit :
> > Dear all,
> >
> > I would like to send different packets to different userland
> > applications using libnetfilter_queue. As far as I understand,
> > different queues can be distingusihed using some kind of queue number.
> > How does the appropriate iptables command look like that sends packets
> > to a specific queue?
>
> This is :
>
> iptables -A .... -j NFQUEUE --queue-num $ID
That was pretty much exactly what I am looking for. Thanks, Eric.
^ permalink raw reply
* Re: [RFC] packet/socket owner match (fireflier) using skfilter
From: Stephen Smalley @ 2006-04-05 15:06 UTC (permalink / raw)
To: edwin; +Cc: James Morris, linux-kernel, fireflier-devel
In-Reply-To: <200604031839.38590.edwin@gurde.com>
On Mon, 2006-04-03 at 18:39 +0300, Török Edwin wrote:
> I am not trying to reinvent SELinux. But I do not know how to accomplish what
> I want with SELinux.
>
> Here it is what I want:
> - have security labels applied to sockets based on their owners (ok, I guess
> SELinux does this by default)
Yes, if owner == creator.
> - the security labels of processes be assigned based on their executable's
> inode+mountpoint.
Not sure what you mean by inode+mountpoint here. SELinux already allows
you to define a domain transition for the process based on the caller's
domain and the type assigned to the executable file via inode extended
attribute.
> Is there a way to do auto-labeling with SELinux? I mean having a security
> context applied based on the inode, without me having to run 'make relabel',
> setfiles, and so on....
Attributes have to be bound to the actual objects, which means that
something has to set those attributes. This is no different than normal
Linux DAC attributes like file owner/group/mode (aside from the need to
use extended attributes for storage). Some package managers have
already been extended to support setting SELinux attributes when files
are installed, like rpm in Fedora, dpkg in Debian unstable, portage in
Hardened Gentoo. install(1) in Fedora also is patched to apply the
proper context for installation of files without using the package
manager. restorecon can be selectively applied to specific files to
restore their labels to the initial values specified in the
configuration.
> Let's say I compile&install a program. Can it have a security label
> auto(magically) applied, based on the inode of its executable? (without
> recompiling, & reloading the policy)
>
> (From my very limited understanding of SELinux, this would mean creating a
> context for each executable, that is altering the policy, if each executable
> needs to have a separate context. Is it possible to dinamically generate the
> context at runtime? Is it possible to integrate my autolabel.c with SELinux?)
If you truly need to distinguish each such program, then yes, they would
need separate contexts, although you likely can organize them into
equivalence classes. You could generate a policy module in userspace
and feed it to semodule to be linked into the base policy and loaded,
although the details are not entirely clear as to what you would need to
put into the policy module (e.g. you seem to just want to define the
domain and type and then make the domain identical to the caller's
domain since you aren't trying to restrict it any further, just use it
for labeling purposes).
> It doesn't have to have a security label applied by its inode, but that is
> unique, I don't know how secure would it be to identify processes by path...
It isn't. Path-based access control considered harmful.
> If the above is possible, could you please provide pointers to documentation?
>
> How can I implement auto-labeling with SELinux? (is there a possibility to
> write some sort of plugins that provide this functionality?)
>
> To sum up, I wrote my LSM stuff because I didn't know how to use SELinux to
> accomplish what I wanted.
> If it can be done with SELinux easily, I'm happy to switch to that. (easy from
> the end-user's perspective, using fireflier for example. it doesn't matter
> how much work it would imply to make fireflier handle the stuff "behind the
> scenes")
You aren't likely to get much review of your actual LSM without breaking
it up into manageable chunks and posting with patches inline for review
to linux-security-module@vger.kernel.org.
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)
From: Randy Smith @ 2006-04-05 15:02 UTC (permalink / raw)
Cc: xenomai
In-Reply-To: <44329D27.1000400@domain.hid>
Philippe Gerum wrote:
>
> Ok, just to be 100% sure, I've just tried the following on a stock
> 2.1.0 grabbed from the mirror:
>
> ../somewhere/xenomai-2.1.0/configure --build=i686-linux
> --host=ppc-linux --prefix=$HOME/xenomai-install CC=ppc_82xx-gcc
> CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld
>
> The resulting tree builds and install fine under $HOME/xenomai-install
> afterwards. There is no kernel dependency whatsoever since the
> user-space support does not even know about the kernel version which
> is going to be used in the first place, so we should be able to get
> the same user-space setup. Could you try rebuilding in a clean build
> tree using equivalent switches at config time, and let me know of the
> outcome? TIA,
>
Philippe,
Thanks for your patient help. I did what you asked and it works fine
for the user side.
The kernel side is what is screwed up. I am using the ELDK 3.1 from the
DENX CD and when I try applying the Adeos patch, it fails in several
places. I ended up applying the patch by hand and I only had a few
places where I was scratching my head as to where to apply the changes
so that might be what I screwed up. Is the
xenomai-2.1.0/ksrc/arch/powerpc/patches/adeos-ipipe-2.4.25-ppc-denx-1.0-03.patch
supposed to apply to the develop tree for ELDK 3.1 instead?? I couldn't
make heads or tails of the numbering scheme used on the patch wrt the
"denx-1.0-03" part.
I'm so close...and I really want to figure this out.
-Randy
^ permalink raw reply
* [U-Boot-Users] Re: [DNX#2006040542000055] [patch] add .gitignore
From: DENX Support System @ 2006-04-05 15:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a follow up
to [DNX#2006040542000055] was entered through the web interface:
<snip>
> Dear Hiroshi Ito,
>
> in message <20060405.233002.48531924.ito@mlb.co.jp> you wrote:
> >
> > * add .gitignore
> > Patch by Hiroshi Ito, 5 Apr 2006
>
> I'm sorry, but for reasons explained before (see mailing list
> archive) I do not *want* to have any .gitignore files in the U-Boot
> tree.
>
> Please bear with me, but I'm so used to this style of working that I
> don't to change it.
>
> Patch rejected.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> You see things; and you say ``Why?'' But I dream things that never
> were; and I say ``Why not?''
> - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1
</snip>
Your U-Boot support team
^ 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.