* [PATCH] e2fsprogs: Fix how we treat user-spcified filesystem size
From: Lukas Czerner @ 2011-02-01 19:18 UTC (permalink / raw)
To: linux-ext4; +Cc: tytso, lczerner
mke2fs and resize2fs allows specifying filesystem size as a parameter,
former called as blocks-count. However it has been a little bit messy so
this commit fixes it mainly by updating man pages.
We can not specify filesystem size in blocks count withou specifying
blocksize as well. It is because we need blocks count to determine
filesystem type, and we need filesystem type to determine blocksize. So
it should not be allowed, however due to compatibility reason it should
be still possible, so at least print warning message for now, so we can
easily restrict that later.
Filesystem size can be specified using units as suffixes. This was not
documented for mke2fs, so this commits adds proper documentation into
mke2fs man page.
For the sake of completeness add 'b' (blocks count) unit.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
---
lib/e2p/parse_num.c | 9 +++++++++
misc/mke2fs.8.in | 40 ++++++++++++++++++++++++++++++++++------
resize/resize2fs.8.in | 8 ++++----
3 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/lib/e2p/parse_num.c b/lib/e2p/parse_num.c
index 83a329a..5e7924b 100644
--- a/lib/e2p/parse_num.c
+++ b/lib/e2p/parse_num.c
@@ -10,6 +10,7 @@
*/
#include "e2p.h"
+#include "../misc/nls-enable.h"
#include <stdlib.h>
@@ -37,6 +38,14 @@ unsigned long long parse_num_blocks2(const char *arg, int log_block_size)
num >>= (1+log_block_size);
break;
case '\0':
+ case 'b':
+ if (!log_block_size) {
+ fprintf(stderr,
+ _("Warning: You can not specify blocks count "
+ "without specifying block size '-b'. Will "
+ "assume kilobytes instead of blocks count!.\n"
+ ));
+ }
break;
default:
return 0;
diff --git a/misc/mke2fs.8.in b/misc/mke2fs.8.in
index 2eead17..67a69b8 100644
--- a/misc/mke2fs.8.in
+++ b/misc/mke2fs.8.in
@@ -108,7 +108,7 @@ mke2fs \- create an ext2/ext3/ext4 filesystem
]
.I device
[
-.I blocks-count
+.I filesystem-size
]
@JDEV@.sp
@JDEV@.B "mke2fs \-O journal_dev"
@@ -136,7 +136,7 @@ mke2fs \- create an ext2/ext3/ext4 filesystem
@JDEV@]
@JDEV@.I external-journal
@JDEV@[
-@JDEV@.I blocks-count
+@JDEV@.I filesystem-size
@JDEV@]
.SH DESCRIPTION
.B mke2fs
@@ -145,15 +145,43 @@ partition.
.I device
is the special file corresponding to the device (e.g
.IR /dev/hdXX ).
-.I blocks-count
-is the number of blocks on the device. If omitted,
-.B mke2fs
-automagically figures the file system size. If called as
+.I filesystem-size
+is the size of the filesystem you want to create.
+If no units are specified, the units of the
+.I filesystem-size
+parameter shall be the blocks count of the filesystem. Keep in mind that
+you can not specify
+.I filesystem-size
+in blocks count without specifying the blocksize as well. This will be
+allowed for now (kilobytes will be assumed)
+due to compatibility reasons, however it may be restricted
+in the future.
+Optionally, the
+.I filesystem-size
+parameter may be suffixed by one of the following the units
+designators: 'b', 's', 'K', 'M', or 'G',
+for blocks count, 512 byte sectors, kilobytes, megabytes, or gigabytes,
+respectively.
+The
+.I filesystem-size
+may never be larger than the size of the partition.
+If
+.I filesystem-size
+parameter is not specified, it will default to the size of the partition.
+If called as
.B mkfs.ext3
a journal is created as if the
.B \-j
option was specified.
.PP
+Note: when kilobytes is used above, I mean
+.IR real ,
+power-of-2 kilobytes, (i.e., 1024 bytes), which some politically correct
+folks insist should be the stupid-sounding ``kibibytes''. The same
+holds true for megabytes, also sometimes known as ``mebibytes'', or
+gigabytes, as the amazingly silly ``gibibytes''. Makes you want to
+gibber, doesn't it?
+.PP
The defaults of the parameters for the newly created filesystem, if not
overridden by the options listed below, are controlled by the
.B /etc/mke2fs.conf
diff --git a/resize/resize2fs.8.in b/resize/resize2fs.8.in
index e02345d..52aaef8 100644
--- a/resize/resize2fs.8.in
+++ b/resize/resize2fs.8.in
@@ -38,13 +38,13 @@ The
parameter specifies the requested new size of the filesystem.
If no units are specified, the units of the
.I size
-parameter shall be the filesystem blocksize of the filesystem.
+parameter shall be the blocks count of the filesystem.
Optionally, the
.I size
parameter may be suffixed by one of the following the units
-designators: 's', 'K', 'M', or 'G',
-for 512 byte sectors, kilobytes, megabytes, or gigabytes, respectively.
-The
+designators: 'b', 's', 'K', 'M', or 'G',
+for blocks count, 512 byte sectors, kilobytes, megabytes, or gigabytes,
+respectively. The
.I size
of the filesystem may never be larger than the size of the partition.
If
--
1.7.2.3
^ permalink raw reply related
* [PATCH v2] release kvmclock page on reset
From: Glauber Costa @ 2011-02-01 19:16 UTC (permalink / raw)
To: kvm; +Cc: linux-kernel, aliguori, Jan Kiszka
When a vcpu is reset, kvmclock page keeps being writen to this days.
This is wrong and inconsistent: a cpu reset should take it to its
initial state.
Signed-off-by: Glauber Costa <glommer@redhat.com>
CC: Jan Kiszka <jan.kiszka@siemens.com>
---
arch/x86/kvm/x86.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bcc0efc..c39ab4a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1453,6 +1453,14 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
return 0;
}
+static void kvmclock_reset(struct kvm_vcpu *vcpu)
+{
+ if (vcpu->arch.time_page) {
+ kvm_release_page_dirty(vcpu->arch.time_page);
+ vcpu->arch.time_page = NULL;
+ }
+}
+
int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
{
switch (msr) {
@@ -1510,10 +1518,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
break;
case MSR_KVM_SYSTEM_TIME_NEW:
case MSR_KVM_SYSTEM_TIME: {
- if (vcpu->arch.time_page) {
- kvm_release_page_dirty(vcpu->arch.time_page);
- vcpu->arch.time_page = NULL;
- }
+ kvmclock_reset(vcpu);
vcpu->arch.time = data;
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
@@ -5814,10 +5819,7 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
{
- if (vcpu->arch.time_page) {
- kvm_release_page_dirty(vcpu->arch.time_page);
- vcpu->arch.time_page = NULL;
- }
+ kvmclock_reset(vcpu);
free_cpumask_var(vcpu->arch.wbinvd_dirty_mask);
fx_free(vcpu);
@@ -5878,6 +5880,8 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
kvm_make_request(KVM_REQ_EVENT, vcpu);
vcpu->arch.apf.msr_val = 0;
+ kvmclock_reset(vcpu);
+
kvm_clear_async_pf_completion_queue(vcpu);
kvm_async_pf_hash_reset(vcpu);
vcpu->arch.apf.halted = false;
--
1.7.2.3
^ permalink raw reply related
* [PATCH] gpu/stub: fix acpi_video build error, fix stub kconfig dependencies
From: Randy Dunlap @ 2011-02-01 19:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: Len Brown, Stephen Rothwell, Luming Yu, linux-next, LKML,
linux-acpi, Linus Torvalds, Andrew Morton, Rafael J. Wysocki
In-Reply-To: <20110201120323.GA6714@elte.hu>
From: Randy Dunlap <randy.dunlap@oracle.com>
The comments under "config STUB_POULSBO" are close to correct,
but they are not being followed. This patch updates them to reflect
the requirements for THERMAL.
This build error is caused by STUB_POULSBO selecting ACPI_VIDEO
when ACPI_VIDEO's config requirements are not met.
ERROR: "thermal_cooling_device_register" [drivers/acpi/video.ko] undefined!
ERROR: "thermal_cooling_device_unregister" [drivers/acpi/video.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/gpu/stub/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--- lnx-2638-rc3.orig/drivers/gpu/stub/Kconfig
+++ lnx-2638-rc3/drivers/gpu/stub/Kconfig
@@ -1,11 +1,13 @@
config STUB_POULSBO
tristate "Intel GMA500 Stub Driver"
depends on PCI
+ depends on NET # for THERMAL
# Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
select ACPI_VIDEO if ACPI
+ select THERMAL if ACPI
help
Choose this option if you have a system that has Intel GMA500
(Poulsbo) integrated graphics. If M is selected, the module will
^ permalink raw reply
* RE: XFS Preallocation
From: Peter Vajgel @ 2011-02-01 19:20 UTC (permalink / raw)
To: Dave Chinner; +Cc: Jef Fox, xfs@oss.sgi.com
In-Reply-To: <20110201080354.GM11040@dastard>
> -----Original Message-----
> From: Dave Chinner [mailto:david@fromorbit.com]
> Sent: Tuesday, February 01, 2011 12:04 AM
> To: Peter Vajgel
> Cc: Jef Fox; xfs@oss.sgi.com
> Subject: Re: XFS Preallocation
>
> On Tue, Feb 01, 2011 at 04:45:09AM +0000, Peter Vajgel wrote:
> > > Preallocation is the only option. Allowing preallocation without
> > > marking extents as unwritten opens a massive security hole (i.e.
> > > exposes stale data) so I say no to any request for addition of such
> > > functionality (and have for years).
> >
> > How about opening this option to at least root (root can already read
> > the device anyway)?.
>
> # ls -l foo
> -rw-r--r-- 1 dave dave 0 Aug 16 10:44 foo
> #
> # prealloc_without_unwritten 0 1048576 foo # ls -l foo
> -rw-r--r-- 1 dave dave 1048576 Aug 16 10:44 foo #
>
> Now user dave can read the stale data exposed by the root only operation. Any
> combination of making the file available to a non-root user after a preallocation-
> without-unwritten-extents
> operation has this problem. IOWs, just making such a syscall "root only" doesn't
> solve the security problem.
Correct - if an admin made prealloc_without_unwritten runnable by any user then yes - but I would argue that such an admin should not even have root privileges. Vxfs had this ability since version 1 and I don't' remember a single customer complaint about this feature. Most of the times the feature was used by db to preallocate large amounts of space knowing that they won't incur any overhead (even transactional) when doing direct io to the pre-allocated range. It could be that at those times even a transactional overhead was significant enough that we wanted to eliminate it.
>
> To fix it, we have to require inodes have 0600 perms, owned by root, and cannot be
> chmod/chowned to anyone else, ever. At that point, we're requiring applications to run
> as root to to use this functionality. Same requirement as fiemap + reading from the
> block device, which you can do right without any kernel mods or filesystem hacks...
>
> > There are cases when creating large
> > files without writing to them is important. A good example is testing
> > xfs overhead when doing a specific workload (like random
> > reads) to large files.
>
> For testing it doesn't matter how long it takes you to write the file in the first place.
At the scale we operate it does. We have multiple variables so the number of combinations is large. We have hit every single possible hardware and software problem and problem resolution can take months if it takes days to reproduce the problem. Hardware vendors (disk, controller, motherboard manufacturers) are much more responsive when you can reproduce a problem on the fly in seconds (especially in comparative benchmarking). The tests usually run only couple of minutes. With 12x3TB (possibly multiplied by a factor of X with our new platform) it would be unacceptable to wait for writes to finish.
>
> > In this case we want to hit the disk on every request. Currently we
> > have a workaround (below) but official support would be preferable.
>
> Officially, we _removed_ the unwritten=0 option from mkfs because of the security
> problems. Not to mention that it was never, ever tested...
>
> >
> > --pv
> >
> >
> > # create_xfs_files
> >
> > dev=$1
> > mntpt=$2
> > dircount=$3
> > filecount=$4
> > size=$5
> >
> > # Umount.
> > umount $2
> >
> > # Create the fs.
> > mkfs -t xfs -f -d unwritten=0,su=256k,sw=10 -l su=256k -L "/hay" $dev
>
> Which fails due to:
>
> unknown option -d unwritten=0
> /* blocksize */ [-b log=n|size=num]
> /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num,
> (sunit=value,swidth=value|su=num,sw=num),
> sectlog=n|sectsize=num .....
It still works for us but we tend to be conservative in moving our releases.
>
> > # Clear unwritten flag - current xfs ignores this flag typeset -i
> > agcount=$(xfs_db -c "sb" -c "print" $dev | grep agcount) typeset -i
> > i=0 while [[ $i != $agcount ]] do
> > xfs_db -x -c "sb $i" -c "write versionnum 0xa4a4" $dev
> > i=i+1
> > done
> >
> > # Mount the filesystem.
> > mount -t xfs -o nobarrier,noatime,nodiratime,inode64,allocsize=1g $dev
> > $mntpt
> >
> > i=0
> > while [[ $i != $dircount ]]
> > do
> > mkdir $mntpt/dir$i
> > typeset -i j=0
> > while [[ $j != $filecount ]]
> > do
> > file=$mntpt/dir$i/file$j
> > xfs_io -f -c "resvsp 0 $size" $file
> > inum=$(ls -i $file | awk '{print $1}')
> > umount $mntpt
> > xfs_db -x -c "inode $inum" -c "write core.size $size" $dev
> > mount -t xfs -o nobarrier,noatime,nodiratime,inode64,allocsize=1g
> > $dev $mntpt
>
> That's quite a hack to work around the EOF zeroing that extending the file size after
> allocating would do because the preallocated extents beyond EOF are not marked
> unwritten. Perhaps truncating the file first, then preallocating is what you want:
>
> xfs_io -f -c "truncate $size" -c "resvsp 0 $size" $file
I think I had it in reverse before - allocate and truncate but the truncate got stuck in a loop (probably zeroing out the extents?) making the node unresponsive to the point that it was impossible to ssh to it. It eventually returned but it took a while. But that was like 3 years ago. If I get to it I'll try the other order.
>
> > j=j+1
> > done
> > i=i+1
> > done
>
> Regardless of all this, perhaps themost important point is that your proposed use of
> XFS is fundamentally unsupportable by the linux XFS
> community: you've got proprietary software on some external hardware writing to the
> disk without going through the linux XFS kernel code.
> You're basically in the same boat as people running proprietary kernel modules -
> unless you can prove the problem is not caused by your hw/sw or manual filesystem
> modifications, then it's a waste of our (limited) resources to even look at the problem.
> That generally comes down to being able to reproduce the problem on a vanilla kernel
> on a filesystem created with a supported mkfs....
Understood. That's why I limit this hack only to testing. I would never even dream to put this into production. Although one could assume that if xfs_check/xfs_repair bless the filesystem before it's mounted you would be safe. But then you might be exposing yourself to bugs in xfs_check/xfs_repair which might have been overlooked since it's not the usual way of using xfs.
Thank you,
Peter
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
From: Kumar Gala @ 2011-02-01 19:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1296579706.1995.60.camel@haiying-laptop>
On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote:
> On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote:
>>>>
>>> If it is a one time setting, there should be no problem to put it into
>>> board code. But these pin settings need to be done before any usage of
>>> phy read/write (accessing MDIO/MDC), and need to be released after the
>>> usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
>>> can be accessed. If we use board code to set/release the pin, we don't
>>> know when the phy access and nand flash access will happen.
>>
>> Is this actually a board issue or an SoC issue?
>>
> It is not a board issue. It is a SoC *feature*. Too many pins are muxed
> on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20]
> which is used for MDIO signal.
>
> Haiying
>
But its a board decision on how they want to utilize those pins and for what feature.
- k
^ permalink raw reply
* Re: [PATCH 1/2] resize2fs: Add support for lazy itable initialization
From: Andreas Dilger @ 2011-02-01 19:15 UTC (permalink / raw)
To: Lukas Czerner; +Cc: linux-ext4, tytso
In-Reply-To: <1296580465-28519-1-git-send-email-lczerner@redhat.com>
On 2011-02-01, at 10:14, Lukas Czerner wrote:
> This commit adds extended options '-E' to the resize2fs code along with
> the first extended option lazy_itable_init=n.
Here it says the option is "=n", is it also possible to force this with "=y"?
> +static void parse_extended_opts(int *flags, const char *opts)
> +{
> + if (!strcmp(token, "lazy_itable_init")) {
> + int lazy;
> + if (arg)
> + lazy = strtoul(arg, &p, 0);
> + else
> + lazy = 1;
> + if (lazy)
> + *flags |= RESIZE_LAZY_ITABLE_INIT;
Here it parses the option as "=0" or "=1", not "=n" or "=y". It looks like "=n" will accidentally return 0 from strtoul(), so that works as expected, but the "=y" option would fail (it would also return 0).
> + if (r_usage) {
> + fprintf(stderr, _("\nBad option(s) specified: %s\n\n"
> + "\tlazy_itable_init=<0 to disable, 1 to enable>\n\n"),
It looks a bit confusing "=<0 to disable", I thought initially that meant any value <= 0 would disable it, though I later see that there is a closing '>'. I think it is more standard to use "{}" braces for "one of these options must be given".
> @@ -232,6 +290,12 @@ int main (int argc, char ** argv)
> + if (access("/sys/fs/ext4/features/lazy_itable_init", R_OK) == 0)
> + flags |= RESIZE_LAZY_ITABLE_INIT;
> +
> + if (extended_opts)
> + parse_extended_opts(&flags, extended_opts);
Good that the command-line options override the default value.
> +.B lazy_itable_init\fR[\fB= \fI<0 to disable, 1 to enable>\fR]
Similarly, this should use "{}" around the options instead of "<>".
> +If enabled and the uninit_bg feature is enabled, the inode table will
> +not be fully initialized by
I would write "not be zeroed out on disk", since it is otherwise unclear
if "not fully initialized" means that there will be less inodes available
or some other issues if the inode table is not "fully" initialized.
Cheers, Andreas
^ permalink raw reply
* [U-Boot] PCIE supported networking cards?
From: Kumar Gala @ 2011-02-01 19:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4D485ABE.9010604@caviumnetworks.com>
We utilize e1000 PCIe cards all the time
- k
On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote:
> Are there any PCIE networking cards that are supported? So far I've
> tried an Intel card and a Realtek RTL8168 card, but neither is
> supported. It looks like the E1000 driver only supports PCI and PCIX
> based cards (Linux uses the e1000e card for PCIe cards).
>
> -Aaron
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply
* Re: [PATCH V2 5/6] powerpc/44x: boot wrapper: allow kernel to load into non-zero address
From: Scott Wood @ 2011-02-01 19:13 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev
In-Reply-To: <1296586126-32765-6-git-send-email-shaggy@linux.vnet.ibm.com>
On Tue, 1 Feb 2011 12:48:45 -0600
Dave Kleikamp <shaggy@linux.vnet.ibm.com> wrote:
> For AMP, different kernel instances load into separate memory regions.
> Read the start of memory from the device tree and limit the memory to what's
> specified in the device tree.
>
> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/boot/treeboot-iss4xx.c | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/treeboot-iss4xx.c b/arch/powerpc/boot/treeboot-iss4xx.c
> index fcc4495..868c8b4 100644
> --- a/arch/powerpc/boot/treeboot-iss4xx.c
> +++ b/arch/powerpc/boot/treeboot-iss4xx.c
> @@ -34,9 +34,28 @@
>
> BSS_STACK(4096);
>
> +static ibm4xx_memstart;
type?
> +static void *iss_4xx_vmlinux_alloc(unsigned long size)
> +{
> + return ibm4xx_memstart;
> }
Doesn't this generate a warning for implicitly casting int to void *?
-Scott
^ permalink raw reply
* [Buildroot] [git commit master 1/1] ruby: don't build documentation when building for host either
From: Peter Korsgaard @ 2011-02-01 19:14 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=b823c04d080016b28c955240ec634764718041bd
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
We don't use it, so it only slows down the build.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/ruby/ruby.mk | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/package/ruby/ruby.mk b/package/ruby/ruby.mk
index adb1862..966a6a1 100644
--- a/package/ruby/ruby.mk
+++ b/package/ruby/ruby.mk
@@ -12,6 +12,8 @@ RUBY_DEPENDENCIES = host-ruby
RUBY_MAKE_ENV = $(TARGET_MAKE_ENV)
RUBY_CONF_OPT = --disable-install-doc
+HOST_RUBY_CONF_OPT = --disable-install-doc
+
# Force optionals to build before we do
ifeq ($(BR2_PACKAGE_BERKELEYDB),y)
RUBY_DEPENDENCIES += berkeleydb
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again
From: Michael Trimarchi @ 2011-02-01 19:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4D47F99D.1080208@free.fr>
Hi
On 02/01/2011 01:16 PM, Albert ARIBAUD wrote:
> Le 01/02/2011 11:45, Michael Trimarchi a ?crit :
>
>> Hi
>>
>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -r -o libat91.o lowlevel_init.o clock.o cpu.o reset.o timer.o
>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: -r and -shared may not be used together
>>
>> I have tried this patch but this a problem releated to linking option. Do you have this problem?
>>
>> Michael
>
> Read up recent posts on the list: this was detected and is fixed in the
> master branch of the u-boot-arm repository.
>
> Amicalement,
I see, but I see but I have other little problem. I have fixed the compilation, but I have a segmentation fault.
Starting program: /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -Bstatic -T u-boot.lds -Ttext 0x23e00000 arch/arm/cpu/arm926ejs/start.o --start-group api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/gadget/libusb_gadget.o
drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o net/libnet.o post/libpost.o board/atmel/at91sam9261ek/libat91sam9261ek.o --end-group /home/michael/u-boot/arch/arm/lib/eabi_compat.o -L /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2 -lgcc -Map u-boot.map -o u-boot
/opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: u-boot: warning: allocated section `.bss' not in segment
Program received signal SIGSEGV, Segmentation fault.
0x08081ebd in elf32_arm_finish_dynamic_sections ()
(gdb) bt
#0 0x08081ebd in elf32_arm_finish_dynamic_sections ()
#1 0x0809cc2b in bfd_elf_final_link ()
#2 0x0807b525 in elf32_arm_bfd_final_link ()
#3 0x0805bfce in ldwrite ()
#4 0x0805a0be in main ()
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timer.patch
Type: text/x-patch
Size: 673 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110201/f1326848/attachment.bin
^ permalink raw reply
* RE: [xen-unstable test] 5482: regressions - FAIL
From: Ian Jackson @ 2011-02-01 19:11 UTC (permalink / raw)
To: Kay, Allen M; +Cc: xen-devel@lists.xensource.com, keir
In-Reply-To: <987664A83D2D224EAE907B061CE93D5301944405A0@orsmsx505.amr.corp.intel.com>
Kay, Allen M writes ("[Xen-devel] RE: [xen-unstable test] 5482: regressions - FAIL"):
> Attached patch disables pci_vtd_quirk for 32-bit Xen since 32-bit xen does not support MMCFG access.
Thanks, that looks like a plausible fix to me so I have applied it.
That way we should avoid getting this failure in our tests again.
CC'd Keir in case he minds the #ifdef or has some other comment to
make.
Ian.
^ permalink raw reply
* [U-Boot] PCIE supported networking cards?
From: Aaron Williams @ 2011-02-01 19:10 UTC (permalink / raw)
To: u-boot
Are there any PCIE networking cards that are supported? So far I've
tried an Intel card and a Realtek RTL8168 card, but neither is
supported. It looks like the E1000 driver only supports PCI and PCIX
based cards (Linux uses the e1000e card for PCIe cards).
-Aaron
^ permalink raw reply
* Re: [poky] [PATCH 2/2] linux-yocto: export kernel configuration audit to the console
From: Bruce Ashfield @ 2011-02-01 19:09 UTC (permalink / raw)
To: Darren Hart; +Cc: yocto, poky, saul.wold
In-Reply-To: <4D485554.1030209@linux.intel.com>
On Tue, Feb 1, 2011 at 1:47 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 02/01/2011 09:25 AM, Bruce Ashfield wrote:
>>
>> Fixes [BUGID #692]
>>
>> Previously the information dumped by the kernel configuration audit
>> scripts was only placed in log files. This isn't as useful as it
>> could be, since they are rarely checked. This change takes the
>> output from kconf_check and explicitly displays it to the user.
>>
>> Signed-off-by: Bruce Ashfield<bruce.ashfield@windriver.com>
>
>> diff --git a/meta/conf/distro/include/poky-default-revisions.inc
>> b/meta/conf/distro/include/poky-default-revisions.inc
>> index 0c3aa9a..ac0de6a 100644
>> --- a/meta/conf/distro/include/poky-default-revisions.inc
>> +++ b/meta/conf/distro/include/poky-default-revisions.inc
>
>> -SRCREV_meta_pn-linux-yocto ?= "8a49ef6f1a43dabbce34a9ee9a1be08b26fc511c"
>> +SRCREV_meta_pn-linux-yocto ?= "e8b8c1ae44932835f4f79e77180d3ce5e4b1ec99"
>
> Was this an intentional change? It wasn't clear to me above which bits
> necessitated a linux-yocto-2.6.37/meta SRCREV change.
Good catch, and typically that would have been a mistake. That's
me updating the captured scripts to have the updated kconf_check
(among others), so it was intentional, but I did for get to mention it
in the submission email.
Cheers,
Bruce
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply
* Re: [PATCH 2/2] linux-yocto: export kernel configuration audit to the console
From: Bruce Ashfield @ 2011-02-01 19:09 UTC (permalink / raw)
To: Darren Hart; +Cc: yocto, poky, saul.wold
In-Reply-To: <4D485554.1030209@linux.intel.com>
On Tue, Feb 1, 2011 at 1:47 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 02/01/2011 09:25 AM, Bruce Ashfield wrote:
>>
>> Fixes [BUGID #692]
>>
>> Previously the information dumped by the kernel configuration audit
>> scripts was only placed in log files. This isn't as useful as it
>> could be, since they are rarely checked. This change takes the
>> output from kconf_check and explicitly displays it to the user.
>>
>> Signed-off-by: Bruce Ashfield<bruce.ashfield@windriver.com>
>
>> diff --git a/meta/conf/distro/include/poky-default-revisions.inc
>> b/meta/conf/distro/include/poky-default-revisions.inc
>> index 0c3aa9a..ac0de6a 100644
>> --- a/meta/conf/distro/include/poky-default-revisions.inc
>> +++ b/meta/conf/distro/include/poky-default-revisions.inc
>
>> -SRCREV_meta_pn-linux-yocto ?= "8a49ef6f1a43dabbce34a9ee9a1be08b26fc511c"
>> +SRCREV_meta_pn-linux-yocto ?= "e8b8c1ae44932835f4f79e77180d3ce5e4b1ec99"
>
> Was this an intentional change? It wasn't clear to me above which bits
> necessitated a linux-yocto-2.6.37/meta SRCREV change.
Good catch, and typically that would have been a mistake. That's
me updating the captured scripts to have the updated kconf_check
(among others), so it was intentional, but I did for get to mention it
in the submission email.
Cheers,
Bruce
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply
* Re: Tracking empty directories
From: Ilari Liusvaara @ 2011-02-01 19:09 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nguyen Thai Ngoc Duy, Jonathan Nieder, Dmitry S. Kravtsov, git,
Shawn Pearce
In-Reply-To: <201102011931.40559.jnareb@gmail.com>
On Tue, Feb 01, 2011 at 07:31:38PM +0100, Jakub Narebski wrote:
> Dnia wtorek 1. lutego 2011 19:15, Ilari Liusvaara napisał:
> >
> > Worse problem than the index: Tree entries. Those are actually transferable
> > and IIRC older (current?) git versions don't handle empty subdirectories
> > (pointing entry of type directory to empty tree hash) all too well...
>
> What did you mean by "don't handle" here? The following entry
>
> 040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty
>
> should be not a problem; empty tree is hardcoded and also shouldn't there
> be a problem with such object. Is the problem when checking out such tree
> (writing to index and/or working area)?
Yes, writing to index/working area. IIRC, having such entry in tree causes
a "ghost directory". I don't exactly recall what such thing broke, but I
remember that it broke something (merging?)...
Those ghosts also had annoying tendency to persist between commits. Commits
didn't kill them. Rm didn't work. You had to create something on top/inside to
get rid of them.
> > Worse yet, there isn't easy way to break the tree parser to avoid current
> > git versions from screwing things up (IIRC, when I tested, invalid octal
> > numbers finally broke it, invalid file types didn't do the trick)...
>
> Well, then 1.8.0 version could be good place to break backwards
> compatibility; we did similar thing when introducing submodule entries,
> isn't it?
Hint: Entry of mode "88888" blows up the tree parser nicely... :-)
At the same time, it could be useful to have manually tracked directories
(incidate via "sticky" bit of tree entry mode?)
-Ilari
^ permalink raw reply
* Re: Tracking empty directories
From: Jakub Narebski @ 2011-02-01 19:03 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Nguyen Thai Ngoc Duy, Dmitry S. Kravtsov, git, Shawn Pearce
In-Reply-To: <20110201183508.GE3771@burratino>
Dnia wtorek 1. lutego 2011 19:35, Jonathan Nieder napisał:
> Nguyen Thai Ngoc Duy wrote:
>> On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>> I have ideas about how to resolve those tricky corner cases, but not
>>> about what the UI should look like. How does one go about adding a
>>> directory? Does it ever get implicitly removed?
>>
>> I suppose a special command for it is appropriate (git-keepdir?). Many
>> index-related commands are recursive by default and hard to change.
>>
>> Yes I think it should be automatically removed from index when a file
>> is added inside tracked directories. Removing those files will also
>> remove the containing directory though.
>
> Okay, I'm convinced. This fits a "worse is better" point of view
> nicely.
>
> To add, one would use "git update-index --add".
Porcelain version could be "git add -N <directory>", don't you agree?
> The magic disappears when you register a file within that directory;
> to tell git you want to keep it, one would mkdir and
> "git update-index --add" again. Once it's working, we can think about
> if there is a need for making that last step automatic after all
> (my guess: "no"). ;-)
Hmmm... could we use mechanism similar to assume-unchanged to mark
directory as explicitely tracked, and that git should not remove it
when it becomes empty?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] xl: fix broken cpupool-numa-split (part 2)
From: Ian Jackson @ 2011-02-01 19:07 UTC (permalink / raw)
To: Juergen Gross
Cc: George Dunlap, Andre Przywara, xen-devel@lists.xensource.com
In-Reply-To: <4D465D1B.1010504@ts.fujitsu.com>
Juergen Gross writes ("Re: [Xen-devel] [PATCH] xl: fix broken cpupool-numa-split (part 2)"):
> On 01/29/11 01:35, Andre Przywara wrote:
> > Before the creation and population of a new CPU pool we have to clear
> > the poolid variable, which still contains the value from the previous
> > iteration.
> > This fixes the execution of xl cpupool-numa-split on machines with more
> > than two nodes.
Applied, thanks.
Ian.
^ permalink raw reply
* latest clutter-recipe
From: Andreas Mueller @ 2011-02-01 19:02 UTC (permalink / raw)
To: openembedded-devel
Hi
it surprised me to see that Koen committed a new recipe for clutter 1.4.2. As you might know I was also working on this and sent some pre-release version here of this (1). What makes me not running in happy mode:
- Many of my previous patches were rejected first because of some commit message. Here we read 'clutter: add 1.4.2' - cool. Which tests were performed?
- the recipe breaks clutter-gst:
| checking for CLUTTER_GST... configure: error: Package requirements (clutter-1.0 < 1.3.0 gio-2.0) were not met:
|
| Requested 'clutter-1.0 < 1.3.0' but version of Clutter is 1.4.2
I prepared clutter-gst 1.3.4 but I am tired preparing commit messages..
- the recipe breaks clutter-gtk :
| NOTE: make -j 4
| make all-recursive
| make[1]: Entering directory `/home/Superandi/tmp/work/armv7a-angstrom-linux-gnueabi/clutter-gtk-0.10.8-r2.0/clutter-gtk-0.10.8'
| Making all in build
| make[2]: Entering directory `/home/Superandi/tmp/work/armv7a-angstrom-linux-gnueabi/clutter-gtk-0.10.8-r2.0/clutter-gtk-0.10.8/build'
| Making all in autotools
| make[3]: Entering directory `/home/Superandi/tmp/work/armv7a-angstrom-linux-gnueabi/clutter-gtk-0.10.8-r2.0/clutter-gtk-0.10.8/build/autotools'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory `/home/Superandi/tmp/work/armv7a-angstrom-linux-gnueabi/clutter-gtk-0.10.8-r2.0/clutter-gtk-0.10.8/build/autotools'
| make[3]: Entering directory `/home/Superandi/tmp/work/armv7a-angstrom-linux-gnueabi/clutter-gtk-0.10.8-r2.0/clutter-gtk-0.10.8/build'
| make[3]: Nothing to be done for `all-am'.
| make[3]: Leaving directory `/home/Superandi/tmp/work/armv7a-angstrom-linux-gnueabi/clutter-gtk-0.10.8-r2.0/clutter-gtk-0.10.8/build'
| make[2]: Leaving directory `/home/Superandi/tmp/work/armv7a-angstrom-linux-gnueabi/clutter-gtk-0.10.8-r2.0/clutter-gtk-0.10.8/build'
| Making all in clutter-gtk
| make[2]: Entering directory `/home/Superandi/tmp/work/armv7a-angstrom-linux-gnueabi/clutter-gtk-0.10.8-r2.0/clutter-gtk-0.10.8/clutter-gtk'
| CC libclutter_gtk_0.10_la-gtk-clutter-embed.lo
| CC libclutter_gtk_0.10_la-gtk-clutter-scrollable.lo
| CC libclutter_gtk_0.10_la-gtk-clutter-viewport.lo
| CC libclutter_gtk_0.10_la-gtk-clutter-util.lo
| CC libclutter_gtk_0.10_la-gtk-clutter-zoomable.lo
| CCLD libclutter-gtk-0.10.la
| /home/Superandi/tmp/sysroots/i686-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: cannot find -lclutter-egl-1.0
Let's hope gtk_0.12 will help...
- What exactly is the goal of 'test-conformance-fix.patch' (to get the build working there less cluttering solutions are possible e.g. sed'ing out BUILIT_SOURCES in Makefile.am)? From my point of view it creates a lot of unusable scripts in the sub folder 'wrapper' and the file 'unit-tests'. Nothing created by this is packed.
Please don't tell me I am invited to change this situation: Many patches send by non-commit guys are nit-picked at least for commit message - and then I read 'clutter: add 1.4.2' for a recipe breaking lots of others.
Sorry for this, but to me the this should have been a hobby for having fun - but at the moment it's far from
Andreas
(1) http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-January/029260.html
^ permalink raw reply
* Re: [PATCH] xl: output illegal option character
From: Ian Jackson @ 2011-02-01 19:06 UTC (permalink / raw)
To: Andre Przywara; +Cc: xen-devel
In-Reply-To: <4D4348CF.6070001@amd.com>
Andre Przywara writes ("[PATCH] xl: output illegal option character"):
> What do you think about the attached one? Looks quite obvious to me.
Yes, applied, thanks.
> Looking at the two patches I hope I can refactor the option parsing into
> common code after the release. This should be easier to fix then.
That would be lovely.
Ian.
^ permalink raw reply
* Re: [PATCH 2/2] security: remove unused security_sysctl hook
From: Stephen Smalley @ 2011-02-01 19:05 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: James Morris, Eric Paris, ebiederm, linux-kernel,
linux-security-module
In-Reply-To: <1296578696-5989-1-git-send-email-lucian.grijincu@gmail.com>
On Tue, 2011-02-01 at 18:44 +0200, Lucian Adrian Grijincu wrote:
> The only user for this hook was selinux. sysctl routes every call
> through /proc/sys/. Selinux and other security modules use the file
> system checks for sysctl too, so no need for this hook any more.
>
> Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> include/linux/security.h | 13 -------------
> kernel/sysctl.c | 5 -----
> security/capability.c | 6 ------
> security/security.c | 5 -----
> 4 files changed, 0 insertions(+), 29 deletions(-)
>
> diff --git a/include/linux/security.h b/include/linux/security.h
> index c642bb8..e7b48dc 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1257,12 +1257,6 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
> * @cap contains the capability <include/linux/capability.h>.
> * @audit: Whether to write an audit message or not
> * Return 0 if the capability is granted for @tsk.
> - * @sysctl:
> - * Check permission before accessing the @table sysctl variable in the
> - * manner specified by @op.
> - * @table contains the ctl_table structure for the sysctl variable.
> - * @op contains the operation (001 = search, 002 = write, 004 = read).
> - * Return 0 if permission is granted.
> * @syslog:
> * Check permission before accessing the kernel message ring or changing
> * logging to the console.
> @@ -1383,7 +1377,6 @@ struct security_operations {
> const kernel_cap_t *permitted);
> int (*capable) (struct task_struct *tsk, const struct cred *cred,
> int cap, int audit);
> - int (*sysctl) (struct ctl_table *table, int op);
> int (*quotactl) (int cmds, int type, int id, struct super_block *sb);
> int (*quota_on) (struct dentry *dentry);
> int (*syslog) (int type);
> @@ -1665,7 +1658,6 @@ int security_capset(struct cred *new, const struct cred *old,
> int security_capable(int cap);
> int security_real_capable(struct task_struct *tsk, int cap);
> int security_real_capable_noaudit(struct task_struct *tsk, int cap);
> -int security_sysctl(struct ctl_table *table, int op);
> int security_quotactl(int cmds, int type, int id, struct super_block *sb);
> int security_quota_on(struct dentry *dentry);
> int security_syslog(int type);
> @@ -1883,11 +1875,6 @@ int security_real_capable_noaudit(struct task_struct *tsk, int cap)
> return ret;
> }
>
> -static inline int security_sysctl(struct ctl_table *table, int op)
> -{
> - return 0;
> -}
> -
> static inline int security_quotactl(int cmds, int type, int id,
> struct super_block *sb)
> {
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 0f1bd83..56f6fc1 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1685,13 +1685,8 @@ static int test_perm(int mode, int op)
>
> int sysctl_perm(struct ctl_table_root *root, struct ctl_table *table, int op)
> {
> - int error;
> int mode;
>
> - error = security_sysctl(table, op & (MAY_READ | MAY_WRITE | MAY_EXEC));
> - if (error)
> - return error;
> -
> if (root->permissions)
> mode = root->permissions(root, current->nsproxy, table);
> else
> diff --git a/security/capability.c b/security/capability.c
> index 2a5df2b..ebe3b5d 100644
> --- a/security/capability.c
> +++ b/security/capability.c
> @@ -12,11 +12,6 @@
>
> #include <linux/security.h>
>
> -static int cap_sysctl(ctl_table *table, int op)
> -{
> - return 0;
> -}
> -
> static int cap_syslog(int type)
> {
> return 0;
> @@ -880,7 +875,6 @@ void __init security_fixup_ops(struct security_operations *ops)
> set_to_cap_if_null(ops, capable);
> set_to_cap_if_null(ops, quotactl);
> set_to_cap_if_null(ops, quota_on);
> - set_to_cap_if_null(ops, sysctl);
> set_to_cap_if_null(ops, syslog);
> set_to_cap_if_null(ops, settime);
> set_to_cap_if_null(ops, vm_enough_memory);
> diff --git a/security/security.c b/security/security.c
> index 739e403..53d793a 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -182,11 +182,6 @@ int security_real_capable_noaudit(struct task_struct *tsk, int cap)
> return ret;
> }
>
> -int security_sysctl(struct ctl_table *table, int op)
> -{
> - return security_ops->sysctl(table, op);
> -}
> -
> int security_quotactl(int cmds, int type, int id, struct super_block *sb)
> {
> return security_ops->quotactl(cmds, type, id, sb);
> --
> 1.7.4.rc1.7.g2cf08.dirty
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: [PATCH 1/2] security/selinux: fix /proc/sys/ labeling
From: Stephen Smalley @ 2011-02-01 19:04 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: James Morris, Eric Paris, Eric W. Biederman, linux-kernel,
linux-security-module
In-Reply-To: <1296578542-5902-1-git-send-email-lucian.grijincu@gmail.com>
On Tue, 2011-02-01 at 18:42 +0200, Lucian Adrian Grijincu wrote:
> This fixes an old (2007) selinux regression: filesystem labeling for
> /proc/sys returned
> -r--r--r-- unknown /proc/sys/fs/file-nr
> instead of
> -r--r--r-- system_u:object_r:sysctl_fs_t:s0 /proc/sys/fs/file-nr
>
> Events that lead to breaking of /proc/sys/ selinux labeling:
>
> 1) sysctl was reimplemented to route all calls through /proc/sys/
>
> commit 77b14db502cb85a031fe8fde6c85d52f3e0acb63
> [PATCH] sysctl: reimplement the sysctl proc support
>
> 2) proc_dir_entry was removed from ctl_table:
>
> commit 3fbfa98112fc3962c416452a0baf2214381030e6
> [PATCH] sysctl: remove the proc_dir_entry member for the sysctl tables
>
> 3) selinux still walked the proc_dir_entry tree to apply
> labeling. Because ctl_tables don't have a proc_dir_entry, we did
> not label /proc/sys/ inodes any more. To achieve this the /proc/sys/
> inodes were marked private and private inodes were ignored by
> selinux.
>
> commit bbaca6c2e7ef0f663bc31be4dad7cf530f6c4962
> [PATCH] selinux: enhance selinux to always ignore private inodes
>
> commit 86a71dbd3e81e8870d0f0e56b87875f57e58222b
> [PATCH] sysctl: hide the sysctl proc inodes from selinux
>
> Access control checks have been done by means of a special sysctl hook
> that was called for read/write accesses to any /proc/sys/ entry.
>
> We don't have to do this because, instead of walking the
> proc_dir_entry tree we can walk the dentry tree (as done in this
> patch). With this patch:
> * we don't mark /proc/sys/ inodes as private
> * we don't need the sysclt security hook
> * we walk the dentry tree to find the path to the inode.
>
> We have to strip the PID in /proc/PID/ entries that have a
> proc_dir_entry because selinux does not know how to label paths like
> '/1/net/rpc/nfsd.fh' (and defaults to 'proc_t' labeling). Selinux does
> know of '/net/rpc/nfsd.fh' (and applies the 'sysctl_rpc_t' label).
>
> PID stripping from the path was done implicitly in the previous code
> because the proc_dir_entry tree had the root in '/net' in the example
> from above. The dentry tree has the root in '/1'.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> fs/proc/proc_sysctl.c | 1 -
> security/selinux/hooks.c | 120 +++++++---------------------------------------
> 2 files changed, 18 insertions(+), 103 deletions(-)
>
> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> index 09a1f92..fb707e0 100644
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -32,7 +32,6 @@ static struct inode *proc_sys_make_inode(struct super_block *sb,
> ei->sysctl_entry = table;
>
> inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
> - inode->i_flags |= S_PRIVATE; /* tell selinux to ignore this inode */
> inode->i_mode = table->mode;
> if (!table->child) {
> inode->i_mode |= S_IFREG;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e276eb4..5231b95 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -43,7 +43,6 @@
> #include <linux/fdtable.h>
> #include <linux/namei.h>
> #include <linux/mount.h>
> -#include <linux/proc_fs.h>
> #include <linux/netfilter_ipv4.h>
> #include <linux/netfilter_ipv6.h>
> #include <linux/tty.h>
> @@ -70,7 +69,6 @@
> #include <net/ipv6.h>
> #include <linux/hugetlb.h>
> #include <linux/personality.h>
> -#include <linux/sysctl.h>
> #include <linux/audit.h>
> #include <linux/string.h>
> #include <linux/selinux.h>
> @@ -1120,39 +1118,35 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
> }
>
> #ifdef CONFIG_PROC_FS
> -static int selinux_proc_get_sid(struct proc_dir_entry *de,
> +static int selinux_proc_get_sid(struct dentry *dentry,
> u16 tclass,
> u32 *sid)
> {
> - int buflen, rc;
> - char *buffer, *path, *end;
> + int rc;
> + char *buffer, *path;
>
> buffer = (char *)__get_free_page(GFP_KERNEL);
> if (!buffer)
> return -ENOMEM;
>
> - buflen = PAGE_SIZE;
> - end = buffer+buflen;
> - *--end = '\0';
> - buflen--;
> - path = end-1;
> - *path = '/';
> - while (de && de != de->parent) {
> - buflen -= de->namelen + 1;
> - if (buflen < 0)
> - break;
> - end -= de->namelen;
> - memcpy(end, de->name, de->namelen);
> - *--end = '/';
> - path = end;
> - de = de->parent;
> + path = dentry_path_raw(dentry, buffer, PAGE_SIZE);
> + if (IS_ERR(path))
> + rc = PTR_ERR(path);
> + else {
> + /* each process gets a /proc/PID/ entry. Strip off the
> + * PID part to get a valid selinux labeling.
> + * e.g. /proc/1/net/rpc/nfs -> /net/rpc/nfs */
> + while (path[1] >= '0' && path[1] <= '9') {
> + path[1] = '/';
> + path++;
> + }
> + rc = security_genfs_sid("proc", path, tclass, sid);
> }
> - rc = security_genfs_sid("proc", path, tclass, sid);
> free_page((unsigned long)buffer);
> return rc;
> }
> #else
> -static int selinux_proc_get_sid(struct proc_dir_entry *de,
> +static int selinux_proc_get_sid(struct dentry *dentry,
> u16 tclass,
> u32 *sid)
> {
> @@ -1316,10 +1310,9 @@ static int inode_doinit_with_dentry(struct inode *inode, struct dentry *opt_dent
> isec->sid = sbsec->sid;
>
> if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
> - struct proc_inode *proci = PROC_I(inode);
> - if (proci->pde) {
> + if (opt_dentry) {
> isec->sclass = inode_mode_to_security_class(inode->i_mode);
> - rc = selinux_proc_get_sid(proci->pde,
> + rc = selinux_proc_get_sid(opt_dentry,
> isec->sclass,
> &sid);
> if (rc)
> @@ -1862,82 +1855,6 @@ static int selinux_capable(struct task_struct *tsk, const struct cred *cred,
> return task_has_capability(tsk, cred, cap, audit);
> }
>
> -static int selinux_sysctl_get_sid(ctl_table *table, u16 tclass, u32 *sid)
> -{
> - int buflen, rc;
> - char *buffer, *path, *end;
> -
> - rc = -ENOMEM;
> - buffer = (char *)__get_free_page(GFP_KERNEL);
> - if (!buffer)
> - goto out;
> -
> - buflen = PAGE_SIZE;
> - end = buffer+buflen;
> - *--end = '\0';
> - buflen--;
> - path = end-1;
> - *path = '/';
> - while (table) {
> - const char *name = table->procname;
> - size_t namelen = strlen(name);
> - buflen -= namelen + 1;
> - if (buflen < 0)
> - goto out_free;
> - end -= namelen;
> - memcpy(end, name, namelen);
> - *--end = '/';
> - path = end;
> - table = table->parent;
> - }
> - buflen -= 4;
> - if (buflen < 0)
> - goto out_free;
> - end -= 4;
> - memcpy(end, "/sys", 4);
> - path = end;
> - rc = security_genfs_sid("proc", path, tclass, sid);
> -out_free:
> - free_page((unsigned long)buffer);
> -out:
> - return rc;
> -}
> -
> -static int selinux_sysctl(ctl_table *table, int op)
> -{
> - int error = 0;
> - u32 av;
> - u32 tsid, sid;
> - int rc;
> -
> - sid = current_sid();
> -
> - rc = selinux_sysctl_get_sid(table, (op == 0001) ?
> - SECCLASS_DIR : SECCLASS_FILE, &tsid);
> - if (rc) {
> - /* Default to the well-defined sysctl SID. */
> - tsid = SECINITSID_SYSCTL;
> - }
> -
> - /* The op values are "defined" in sysctl.c, thereby creating
> - * a bad coupling between this module and sysctl.c */
> - if (op == 001) {
> - error = avc_has_perm(sid, tsid,
> - SECCLASS_DIR, DIR__SEARCH, NULL);
> - } else {
> - av = 0;
> - if (op & 004)
> - av |= FILE__READ;
> - if (op & 002)
> - av |= FILE__WRITE;
> - if (av)
> - error = avc_has_perm(sid, tsid,
> - SECCLASS_FILE, av, NULL);
> - }
> -
> - return error;
> -}
> -
> static int selinux_quotactl(int cmds, int type, int id, struct super_block *sb)
> {
> const struct cred *cred = current_cred();
> @@ -5398,7 +5315,6 @@ static struct security_operations selinux_ops = {
> .ptrace_traceme = selinux_ptrace_traceme,
> .capget = selinux_capget,
> .capset = selinux_capset,
> - .sysctl = selinux_sysctl,
> .capable = selinux_capable,
> .quotactl = selinux_quotactl,
> .quota_on = selinux_quota_on,
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: OE TSC
From: Mark Hatle @ 2011-02-01 19:02 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1296579133.13501.19996.camel@rex>
On 2/1/11 10:52 AM, Richard Purdie wrote:
> On Tue, 2011-02-01 at 15:51 +0100, Koen Kooi wrote:
>> On 31-01-11 15:10, Richard Purdie wrote:
>>
>>> There are various issues needing attention ASAP and therefore the TSC
>>> would like to propose that we call for candidates and that the board
>>> then empower an interim TSC based on the result of that call without
>>> waiting for a vote.
>>
>> Since I'll be travelling the rest of the week and will likely be offline
>> when the actual call comes from the board:
>>
>> I would like to stand as candidate for that interim TSC.
>>
>> Earlier Khem and Tom Rini expressed interest in standing as candidate as
>> well, but I can't say if that is still the case. Please speak up if it is :)
>>
>> It would be nice to have someone with an interest in the releases as
>> well, e.g. Stefan Schmidt.
>
> So just for completeness I've also wondered whether anyone from the
> Yocto world would be welcome on the TSC, in particular I think Mark
> Hatle might have a lot to offer.
>
> I appreciate he isn't know much in the OE world but he has a strong
> background in embedded Linux (works for Wind River) and is a strong
> participant in the Yocto community. Some OE people met him in Cambridge
> since he was at OEDEM.
As Richard mentioned, I'm likely not well known within the OE community.
However, I am willing to serve on the TSC and bring my experience in embedded
Linux with me. I've worked with both Khem and Tom both in an Open Source
capacity as well as professionally in the past.
As a quick bio, let me share my background.
Back in around 1997 I started working on MkLinux (Mach Microkernel based Linux)
on the old Power Macs. I was one of the first people (maybe the first?) to
integrate a full 'modern' Linux distribution on a PowerPC based machine. This
eventually lead to MkLinux, LinuxPPC and even early Yellow Dog Linux releases..
Since 2000 I've been working on embedded Linux projects. In 2000 I was hired as
an engineer with MontaVista Software. My responsibilities covered everything
from build systems, to toolchains, to userspace integration...
In 2005 I moved to my present employer, Wind River, and repeated many of my
previous assignments.. build systems, toolchains, package management and
userspace integration.
Since 2008, I've been involved with the GENIVI automotive organization. I
helped in the early days determine open source strategies, as well as was the
chair for the System Infrastructure working group.
Since 2010, I've been involved with the Yocto project since the beginning. This
was my first experience with an OE style build environment, but the general
every day work, toolchains, userspace integration, package management are all
the same problems as I've encountered numerous times in the past.
I hope this gives a quick background of my qualifications. If anyone has any
questions, I'll be happy to answer them.
Thanks,
--Mark
^ permalink raw reply
* Re: How To Temporarily Suspend Network Traffic
From: Volkan YAZICI @ 2011-02-01 18:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Rick Jones, netdev
In-Reply-To: <20110201094923.4fa6637f@nehalam>
On Tue, 1 Feb 2011 09:49:23 -0800, Stephen Hemminger writes:
> What about using tc mired to redirect to dummy device? or use netem drop
Ohh! I have just heard about netem. I'll definitely give it a try.
Thanks!
Regards.
P.S. I will ofcourse google and read the documentation that I can find
about these stuff. OTOH, I'd be really appreciated if you can point
me some relevant material. Kind of material, that is, which might
not be able to easily reachable via searching and following links.
^ permalink raw reply
* Re: snd_soc_jack_add_gpios vs. SOC_DAPM_PIN_SWITCH
From: Stephen Warren @ 2011-02-01 18:59 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel@alsa-project.org
In-Reply-To: <20110201113351.GB12743@opensource.wolfsonmicro.com>
Mark Brown wrote at Tuesday, February 01, 2011 4:34 AM:
> On Mon, Jan 31, 2011 at 04:03:58PM -0800, Stephen Warren wrote:
>
> > However, if I use the control to disable the headphones, then
> > unplug/replug the headphones, the jack detect seems to override
> > the control, and I hear audio from the headphones.
>
> Using these two together makes no sense. Either you manually control
> the state of the output or you manage it automatically.
I was thinking that the jack detect would be used to enable/disable widgets
for power purposes, but with a manual override to allow SW to set up use
cases where only the internal speakers were used, and never headphones.
That said, if that isn't something that's ever typically done, I'm fine
not supporting that.
> Generally a PIN_SWITCH() should only be used to offer control if none is
> availabile within the CODEC - in the case of Harmony it wouldn't make
> much sense as there's plenty of control in the CODEC for what gets
> routed to the various outputs.
IIRC, the codec controls allow selecting only what gets routed, but there
wasn't an overall "enable/disable speakers" switch (the mute switch does
not disable the DAPM widgets). One would have to disable all the routing
options to disable the speaker amplifiers, which would entail remembering
what those routing options were to restore them once the speakers were
desired again. A manual switch avoids this.
--
nvpublic
^ permalink raw reply
* Re: [PATCH 2/3] t9010-svn-fi: Add tests for svn-fi
From: Jonathan Nieder @ 2011-02-01 18:58 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, David Barr, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <1296570403-9082-3-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> Create a test-svn-fi in toplevel directory, add rules to build it, and
> add some basic tests.
Thanks. Probably this should be squashed with patch #1?
> --- /dev/null
> +++ b/t/t9010-svn-fi.sh
Test number's already taken. 9012 is free, though.
> @@ -0,0 +1,303 @@
> +#!/bin/sh
> +
> +test_description='check svn dumpfile exporter'
> +
> +. ./test-lib.sh
> +
> +if ! svnadmin -h >/dev/null 2>&1
> +then
> + skip_all='skipping svn-fi tests, svn not available'
> + test_done
> +fi
Is it impossible to test without svn present or otherwise speed
these up? Some random ideas:
- feed svn-fi output into svn-fe and compare git repos
- check if "svn-fi after svn-fe" is idempotent (should it be?)
- check for individual salient features from svn-fi output, using
"grep", "sed", or "awk" to ignore the rest
- use svnrdump in place of "svnadmin load" if available (is it
faster?)
- find the bottleneck in svnadmin and fix it
Of course at least one test of the "svn-fe | svnadmin load"
pipeline seems worthwhile; I'm just thinking we should avoid
habits that slow down the test suite too much.
> +svn_look () {
> + subcommand=$1 &&
> + shift &&
> + svnlook "$subcommand" "$svnrepo" "$@"
> +}
Needed? The svn_cmd function exists to point to a configuration
directory.
> +test_expect_success 'normal empty files' '
> + reinit_svn &&
> + cat >expect.tree <<-\EOF &&
> + /
> + foo
> + bar
> + EOF
> + cat >input <<-\EOF &&
> + reset refs/heads/master
> + commit refs/heads/master
> + mark :1
> + author nobody <nobody@localhost> 1170199019 +0100
> + committer nobody <nobody@localhost> 1170199019 +0100
Where do the dates come from? Why should I (the reader) expect
them?
> +# TODO: How to test date? Need to convert from local timestamp
Ah, you saw. :)
One possibility is to fuzz away whatever is unimportant when
comparing results (and using tools like "awk" to extract the
date to perform whatever tests on it are appropriate where it
matters).
> +test_expect_success 'malformed fast-import stream: author 2' '
> + reinit_svn &&
> + cat >input <<-\EOF &&
> + reset refs/heads/master
> + commit refs/heads/master
> + mark :1
> + author nobody <localhost> 1170199019 +0100
> + committer nobody <nobody@localhost> 1170199019 +0100
> + data 0
> + M 100644 inline foo
> + data 0
> +
> + EOF
> + try_load input must_fail
What's wrong with this stream?
> +test_expect_success 'svn:special and svn:executable' '
> + reinit_svn &&
> + cat >input <<-\EOF &&
> + reset refs/heads/master
> + commit refs/heads/master
> + mark :1
> + author nobody <nobody@localhost> 1170199019 +0100
> + committer nobody <nobody@localhost> 1170199019 +0100
> + data 7
> + nothing
> + M 100755 inline foo
> + data 0
> + M 755 inline moo
> + data 0
> + M 120000 inline bar
> + data 0
> +
> + EOF
> + try_load input &&
> + svn_look propget svn:executable foo &&
> + svn_look propget svn:executable moo &&
> + svn_look propget svn:special bar
Maybe worth checking for the absence of svn:executable +
svn:special from an ordinary file, too?
> +test_expect_success 'replace symlink with normal file' '
Nice. "replace symlink with executable" and "replace symlink
with directory" might also be interesting.
Regards,
Jonathan
^ 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.