Re: man command fails with aufs
On Thu, 2019-10-24 at 16:57 +0900, J. R. Okajima wrote: > > In the log, at the very early stage line 894, aufs produces BUG msg. > ::: > > It happened when mkdir[847] issues exit(2). At exitting, all opened > > file descriptors are closed by kernel and aufs_release_dir() is called. > > By enabling CONFIG_AUFS_DEBUG, aufs checks the state of the internal > > lock and found it is still locked which sould not happen. I don't think > > it sane. I am really doubtful "Is it really correctly built?" > > Reading the source files of debian kernel 4.19.67-2+deb10u1, I've found > a suspicious thing. > - aufs4-mmap.patch is applied in-correctly, > or in-correct version is applied, > or bad aufs version which contained a in-correct version is used. > > The last part of mm/nommu.c:do_mmap(), > fput(vma->vm_file); > should be > vma_fput(vma); [...] I think I noticed this a while ago, but since Debian doesn't run on nommu systems I didn't bother fixing it. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
Re: aufs release will be late
On Thu, 2016-11-03 at 04:35 +0900, sf...@users.sourceforge.net wrote: > Hello Scooby, > > Shraptor Shraptor: > > Does your current release include any kernels were dirtyc0w bug is > > fixed? > > > Would you explain what dirtyc0w bug is? It's a memory management bug, designated CVE-2016-5195. The fix didn't conflict with aufs-standalone for 3.2 or 3.16, and I would be surprised if it conflicts with current aufs. Shraptor, if you are using a recent aufs branch you should be able to cherry-pick commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 cleanly. Alternately, apply the aufs-standalone patches on top of a stable branch that has been fixed. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi
Re: aufs3 and aufs4 GIT release
On Sat, 2016-02-20 at 09:14 +0100, Philip Müller wrote:
> Hi,
>
> forget about it. It was my bad. I've something in my create-aufs.sh
> patch. Have to remember why I added it ...
>
> grep -qse 'EXPORT_SYMBOL(' aufs3-standalone.patch && \
> sed -i-old -e 's|EXPORT_SYMBOL(|EXPORT_SYMBOL_GPL(|' aufs3-standalone.patch
I don't know why _you_ added it, but I've always done that same
substitution when integrating aufs into the Debian package.
My reasoning was that if a function is not already exported, it must be
intended as "an internal implementation issue, and not really an
interface" which is precisely where EXPORT_SYMBOL_GPL is appropriate
<https://www.kernel.org/doc/htmldocs/kernel-hacking/sym-exportsymbols-gpl.html>.
Okajima-san, please consider following this practice.
Ben.
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
signature.asc
Description: This is a digitally signed message part
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
Re: concurrent msync triggers NULL pointer dereference
On Wed, 2015-09-16 at 08:42 +0200, Xavier Chantry wrote: > On 2015-09-15 20:14, sf...@users.sourceforge.net wrote: > > > > I will merge your patch and release after completing my local > > tests. > > Thank you. > > > > > > Glad you came to an agreement, thank you both for your time. > > @Ben: > will all debian kernels be patched ? 3.16 in wheezy-backports and > jessie, 4.1 in jessie-backports, stretch and sid ? Yes. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part --
Re: concurrent msync triggers NULL pointer dereference
On Fri, 2015-09-11 at 12:04 +0900, sf...@users.sourceforge.net wrote: > Ben Hutchings: > > I don't see any need for holding a reference to vma->vm_prfile here. > > > > There is also a similar bug in madvise_remove() which I can trigger by > > calling madvise(..., MADV_REMOVE) in parallel with another thread that > > does mmap() and munmap() of the same address range. > > Did you test mmap()/munmap() using the same opened-file-object with the > original mmap/madvise? Yes. > As I wrote in > http://www.openwall.com/lists/oss-security/2015/09/10/4 > I still think to get/put(vm_prfile) is necessary. I think it doesn't matter when the last reference is from a running system call and not a vma. There is no way that the process could use the aufs file structure at this point. > > This bug has some security impact (at least a minor DoS, but possible > > privilege escalation) so I'm going to request a CVE ID for it. > > Would you explain the possible scenario of the privilege escalation? In general: while one task is about to use freed memory, another task can race to reallocate that memory, and it may be possible for an attacker to arrange that the initialisation by the second task will cause the first task to jump to attacker-controlled code. I think it's unlikely in this case because there is a specific slab cache for struct vm_area_struct and so it can't be aliased with some other type, but it's still a possibility. Ben. --
Re: concurrent msync triggers NULL pointer dereference
On Thu, 2015-09-03 at 01:21 +0900, sf...@users.sourceforge.net wrote:
> sf...@users.sourceforge.net:
> >
> > Xavier Chantry:
> > > I can reproduce the bug on all my machines, so it shouldn't be too
> > > difficult to reproduce. Applying the following hunk is enough to trigger
> > > the bug.
> >
> > Unfortunately still I don't have enough time.
> > I understand this bug has a big impact for you and any other user who
> > have applied aufs3-mmap.patch. As soon as I get the time, I'm sure I
> > will dive into this problem.
>
> I've thought about the problem a little (still I'm busy).
> It looks like a race condition around mm->mmap_sem.
>
> - get_file(file);
> + vma_get_file(vma);
> up_read(>mmap_sem);
> error = vfs_fsync(file, 0);
> - fput(file);
> + vma_fput(vma);
> if (error || start >= end)
> goto out;
> down_read(>mmap_sem);
>
> Since this fput/vma_fput is between up(mmap_sem) and down(mmap_sem),
> vma_fput() is not protected, and got vm_file NULL unexpectedly. It
> means vma->vm_file is changed (or being changed) by someone else (other
> thread in your case) after up_read(>mmap_sem). This is surely a bug
> in aufs[34]-mmap.patch. It shoule be done such like this essentially.
> get_file(file);
> pr = vma->vm_prfile;
> ;;;
> fput(file);
> if (pr)
> fput(pr);
>
> The fix will look a little smarter than above.
> I hope I can post the fix in a few weeks.
I don't see any need for holding a reference to vma->vm_prfile here.
There is also a similar bug in madvise_remove() which I can trigger by
calling madvise(..., MADV_REMOVE) in parallel with another thread that
does mmap() and munmap() of the same address range.
This patch against 3.16 fixes both for me:
From: Ben Hutchings <b...@decadent.org.uk>
Date: Thu, 10 Sep 2015 02:19:59 +0100
Subject: aufs3: mmap: Fix races in madvise_remove() and sys_msync()
Bug-Debian: https://bugs.debian.org/796036
In madvise_remove() and sys_msync() we drop the mmap_sem before
dropping references to the mapped file(s). As soon as we drop the
mmap_sem, the vma we got them from might be destroyed by another
thread, so calling vma_do_fput() is a possible use-after-free.
In these cases we don't actually need a reference to the aufs file, so
revert to using get_file() and fput() directly.
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -327,12 +327,12 @@ static long madvise_remove(struct vm_are
* vma's reference to the file) can go away as soon as we drop
* mmap_sem.
*/
- vma_get_file(vma);
+ get_file(f);
up_read(>mm->mmap_sem);
error = do_fallocate(f,
FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
offset, end - start);
- vma_fput(vma);
+ fput(f);
down_read(>mm->mmap_sem);
return error;
}
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -84,13 +84,13 @@ SYSCALL_DEFINE3(msync, unsigned long, st
start = vma->vm_end;
if ((flags & MS_SYNC) && file &&
(vma->vm_flags & VM_SHARED)) {
- vma_get_file(vma);
+ get_file(file);
up_read(>mmap_sem);
if (vma->vm_flags & VM_NONLINEAR)
error = vfs_fsync(file, 1);
else
error = vfs_fsync_range(file, fstart, fend, 1);
- vma_fput(vma);
+ fput(file);
if (error || start >= end)
goto out;
down_read(>mmap_sem);
--- END ---
This bug has some security impact (at least a minor DoS, but possible
privilege escalation) so I'm going to request a CVE ID for it.
Ben.
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
Re: aufs4 fails to build on 4.0 - Debian
On Fri, 2015-07-24 at 19:26 +0100, OmegaPhil wrote: On Monday 25 May 2015 04:55 PM, sf...@users.sourceforge.net wrote: Ritesh Raj Sarraf: Anyways, in the standalone tree, there are a bunch of patches with no order defined. Is it to assume that they can all be applied randomly ? No. Please refer to README file in aufs4-standalone.git. Yup. That one explain. Sorry. I completely missed that file. I was hoping if we can have a standalone/dkms tree, which could build a kernel module out, easily loadable in the respective kernel ?? Patching is neccessary (by either manually or GIT), which means you will need another kernel as long as debian kernel is unpatched. Then it may not fit in the bill of dkms. Let me check with Ben on how he supported it for Jessie. Did this go anywhere? I'm on Debain Testing, the recent upgrade to v4 kernel completely bricked aufs volumes on the 2 machines I use it on locally because they removed this (and where was the acceptability of such a removal discussed? Nothing comes up on a search)... The aufs patches to the kernel are included in Debian packages again as of Linux 4.1 which will go into unstable soon. You will still have to build the module separately. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part --
Detecting access by the HSM daemon
au_cmoo() does: pid = au_fhsm_pid(fhsm); if (pid (current-pid == pid || current-real_parent-pid == pid)) goto out; But the kernel's 'pid' is really a thread ID. If the HSM daemon is multithreaded, only one of its threads will get be recognised. I think that the HSM daemon should be recognised based on 'tgid' (task group ID, POSIX process ID). Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
Re: ext2 and ext4 fsck errors when using aufs
On Tue, 2014-07-29 at 14:21 -0500, Jacob Burkamper wrote: dpkg -l aufs-tools gives the following output: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii aufs-tools 1:3.0+2001-1ubuntu1 Tools to manage aufs filesystems The $AUFS_VERSION variable gives 3.x-rcN-20111205, dpkg shows the package version as 1:3.0+2001-1ubuntu1, and modinfo aufs gives the module as version 3.13-20140303. Which is to be believed? There is a big difference between December 2011 and March 2014. Ubuntu (and Debian) packages the aufs module as part of the kernel, so its version can easily be inconsistent with the userland aufs-tools package. When you say the $AUFS_VERSION variable, do you mean the macro definition in /usr/include/linux/aufs_type.h? This is built from the kernel source but can again be a different version from the installed kernel (it's in the linux-libc-dev package). So, which to believe? All of them, as they refer to different parts of aufs... Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. signature.asc Description: This is a digitally signed message part -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
Re: aufs BUG on linux 3.10.27
On Tue, 2014-01-28 at 21:00 +0100, François wrote: Hi again, I'll post more when I confirm, but I'm pretty sure it has something to do with this issue. BTW: Do you know loop-aes? If so, can it be patched to make 3.10.x work? It used to work with aufs in the 3.0.x kernel. I confirm it's actually my issue. I use loop-aes v3.7a downloaded there: http://loop-aes.sourceforge.net/loop-AES/ But aufs3-loopback.patch doesn't apply well on the modified loop.c from loop-aes. Do you have another patch for loop-aes support? I can try to adapt the current one if you think there is a chance that it might work. Why not switch to dm-crypt? It can support all encryption modes used by loop-aes, so there is no need to convert any existing volumes. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
Re: aufs3.12 will kill aufs3.{2,2.x,4} (Re: aufs3 GIT release)
On Mon, 2013-09-30 at 13:17 +0900, sf...@users.sourceforge.net wrote: Ben Hutchings: So far as I could tell, the rest were new features - which aren't suitable for a Debian stable update - or adding donors to the documentation. Are you concerned that some bug fix might have a dependency I didn't notice? I understand that there are unimportant (for debian) commits in all 85, and you exclude them. But the commit list I wrote in my previous mail contains important ones. So they are recommendation from me. Of course the choice is yours. If we think the word bugfix strictly, you should pick ca0e87b 2013-04-20 aufs: new copyup 6/6, the inode attributes 724b70b 2013-04-20 aufs: new copyup 5/6, actually unlock the parent and relock ead9579 2013-04-20 aufs: new copyup 4/6, aufs_rename() always copies-up the src dentry 8b550ff 2013-04-20 aufs: new copyup 3/6, aufs_link() copyup dentry using src_dentry's name 8a4170f 2013-04-20 aufs: new copyup 2/6, au_pin supports temporary unlock/relock c90d846 2013-04-20 aufs: new copyup 1/6, copyup as a hidden name too. They are for the bug Al Viro pointed out. As my very personal opinion, the problem will not occur while it is surely a bug. Theoritically it should be fixed and these commits did. These are quite big changes that seem to carry a risk of regression (in fact you listed several fixes for regressions). Since you say the bug being fixed is not that big a risk itself, this does not seem like a sensible change for a stable update - particularly as you won't provide any further regression fixes for 3.2.x. I can change the version string again if you think it should have 'debian' in it. Yes please. It is important. I will do this but it is now too late to include this change in the Debian 7.2 point release. Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, reading IRC for the first time signature.asc Description: This is a digitally signed message part -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
Re: aufs3.12 will kill aufs3.{2,2.x,4} (Re: aufs3 GIT release)
On Mon, 2013-09-30 at 12:33 +0900, sf...@users.sourceforge.net wrote: Hello Ben, Ben Hutchings: Thanks for maintaining the 3.2.x branch. I didn't take all the changes from it but I cherry-picked these to include in a stable update for the Debian kernel: The current version of aufs in debian is aufs3.2 20130204, right? 28de369 2013-02-04 aufs3.2 20130204 And if we run git log --no-merges 28de369..aufs3.2.x, we get 85 commits. You chose 12 of them and I guess you want the fixes for critical problmes only, but I'd suggest you to pick up all 85, including the updated version string. So far as I could tell, the rest were new features - which aren't suitable for a Debian stable update - or adding donors to the documentation. Are you concerned that some bug fix might have a dependency I didn't notice? If you really really don't want all, I'd suggest you to pick these commits too and change the version string to something like debianized 20130204. [...] Well I also cherry-picked the change of version string to '3.2.x', which seemed suitably ambiguous. :-) The Debian changelog lists the cherry-picked changes. I can change the version string again if you think it should have 'debian' in it. Ben. -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. signature.asc Description: This is a digitally signed message part -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
[PATCH] aufs: mvdown, don't let unprivileged users provoke a WARNING
Move the WARN_ONCE() about mvdown after the capability check.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
This is compile-tested only.
Ben.
fs/aufs/ioctl.c | 1 -
fs/aufs/mvdown.c | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/aufs/ioctl.c b/fs/aufs/ioctl.c
index 628d627..1ac7688 100644
--- a/fs/aufs/ioctl.c
+++ b/fs/aufs/ioctl.c
@@ -152,7 +152,6 @@ long aufs_ioctl_nondir(struct file *file, unsigned int cmd,
unsigned long arg)
switch (cmd) {
case AUFS_CTL_MVDOWN:
- WARN_ONCE(1, move-down is still testing...\n);
err = au_mvdown(file-f_dentry, (void __user *)arg);
break;
diff --git a/fs/aufs/mvdown.c b/fs/aufs/mvdown.c
index e68002e..5f56645 100644
--- a/fs/aufs/mvdown.c
+++ b/fs/aufs/mvdown.c
@@ -489,6 +489,8 @@ int au_mvdown(struct dentry *dentry, struct aufs_mvdown
__user *uarg)
if (unlikely(!capable(CAP_SYS_ADMIN)))
goto out;
+ WARN_ONCE(1, move-down is still testing...\n);
+
err = -ENOMEM;
args = kmalloc(sizeof(*args), GFP_NOFS);
if (unlikely(!args))
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
signature.asc
Description: This is a digitally signed message part
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
Re: aufs3 GIT release
On Mon, 2013-08-05 at 09:40 +0900, sf...@users.sourceforge.net wrote: o news - For aufs3.x-rcN, I made a change about CONFIG_AUFS_BDEV_LOOP again, and I have a plan to do it once more. [...] Surely this needs to depend on BLK_BDEV_LOOP=y AUFS=y? Or else you could add an EXPORT_SYMBOL for loop_backing_file(). Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
Re: aufs3.0 .. aufs3.5 will end
On Mon, 2013-04-08 at 01:11 +0200, Thanatermesis wrote: I have recently found that aufs sometimes fails when installing packages with the default debian/wheezy kernel, the release of debian is very near so I think that is important to see how important is this problem, I found it after to see that strange things happens on live mode (sorry, I dont remember them right now) which conducted me to found these messages in dmesg: [ 254.060377] [ cut here ] [ 254.060439] WARNING: at /build/buildd-linux_3.2.39-2-i386-4VFKqr/linux-3.2.39/fs/aufs/plink.c:418 au_plink_append+0xed/0x272 [aufs]() [ 254.060441] Hardware name: VirtualBox [ 254.060442] unexpectedly many pseudo links, 101 This doesn't look like a failure, it looks like a warning about a case where aufs is not very efficient. Whenever you upgrade a package, dpkg creates temporary hard links to preserve the files from the old version in case it needs to abort the upgrade. It is not possible to create hard links between filesystems, so if you create a hard link to a file that has not been copied-up, aufs will create a 'pseudo link' on the upper filesystem which seems to be similar to a whiteout entry. aufs appears to maintain a single list of pseudo links per aufs filesystem, which will make it slow whenever there are a lot of them. Hence the warning. Ben. [ 254.060444] Modules linked in: snd_pcm_oss snd_mixer_oss psmouse serio_raw evdev pcspkr snd_intel8x0 snd_ac97_codec snd_pcm snd_page_alloc snd_timer i2c_piix4 parport_pc snd parport i2c_core soundcore ac97_bus ac power_supply processor button thermal_sys squashfs loop aufs(C) nls_utf8 isofs sd_mod crc_t10dif sg sr_mod cdrom ohci_hcd ata_generic ehci_hcd ahci usbcore libahci ata_piix usb_common libata e1000 scsi_mod [last unloaded: scsi_wait_scan] [ 254.060479] Pid: 3739, comm: dpkg Tainted: G C 3.2.0-4-686-pae #1 Debian 3.2.39-2 [ 254.060480] Call Trace: [ 254.060497] [c10383c4] ? warn_slowpath_common+0x68/0x79 [ 254.060503] [f833e649] ? au_plink_append+0xed/0x272 [aufs] [ 254.060506] [c103843d] ? warn_slowpath_fmt+0x29/0x2d [ 254.060520] [f833e649] ? au_plink_append+0xed/0x272 [aufs] [ 254.060534] [f833243d] ? au_sio_cpup_single+0xa0/0xb4 [aufs] [ 254.060543] [c10da517] ? dput+0x21/0xc2 [ 254.060549] [f833bb24] ? aufs_link+0x36a/0x67c [aufs] [ 254.060554] [f833a651] ? h_permission.isra.20+0x8e/0xda [aufs] [ 254.060557] [c10d5128] ? vfs_link+0x9d/0xde [ 254.060558] [c10d69af] ? sys_linkat+0x147/0x180 [ 254.060560] [c10d69fb] ? sys_link+0x13/0x17 [ 254.060568] [c12c2644] ? syscall_call+0x7/0xb [ 254.060571] [c12c] ? ec_install_handlers+0x74/0x85 [ 254.060573] ---[ end trace 8049851b73698197 ]--- Please contact me for any possible test required with the issue, Im also available on IRC freenode at the Thanatermesis nickname Thanks Thanatermesis -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
Re: aufs3.0 .. aufs3.5 will end
On Sat, 2013-04-06 at 18:02 +0900, sf...@users.sourceforge.net wrote: Ben Hutchings: The base kernel is the 3.2.y stable/longterm branch which I'm maintaining at kernel.org. It was updated from 3.2.39 to 3.2.41 today. Hmm, so the y can grow in the future... Then I will try creating and releasing aufs3.2.x branch, which will contain aufs3.2.41 tag. If I have enough time, I will follow your future update as aufs3.2.42, 43... How long will the debian 3.2 kernel be kept, do you guess? Debian supports each stable release until 1 year after the next release. Given the current 2 year cycle, that means early 2016. Ben. -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman, Secretary of the US Navy 1981-1987 signature.asc Description: This is a digitally signed message part -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
Re: aufs3.0 .. aufs3.5 will end
On Sat, 2013-04-06 at 11:08 +0900, sf...@users.sourceforge.net wrote: Ben Hutchings: In Debian 7.0 we will use Linux 3.2 and aufs3.2 for the Debian Live images. We have no need for new features, but if you could keep backporting important bug fixes that would be appreciated. Your base kernel is 3.2.39 instead of 3.2.0, right? The base kernel is the 3.2.y stable/longterm branch which I'm maintaining at kernel.org. It was updated from 3.2.39 to 3.2.41 today. Ben. -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman, Secretary of the US Navy 1981-1987 signature.asc Description: This is a digitally signed message part -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
Re: aufs3.0 .. aufs3.5 will end
On Thu, 2013-03-28 at 21:27 +0900, sf...@users.sourceforge.net wrote: Hello all, I have a plan to stop maintaining aufs3.0 .. aufs3.5. If you have a strong objection, please let me know. In Debian 7.0 we will use Linux 3.2 and aufs3.2 for the Debian Live images. We have no need for new features, but if you could keep backporting important bug fixes that would be appreciated. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
[PATCH] Use correct comparison with root uid
We should use uid_eq() to compare uids, and GLOBAL_ROOT_UID as
the root uid.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
This has no practical effect, but in the wonderful future when user
namespaces work the current comparisons will fail to compile.
Ben.
fs/aufs/inode.c |2 +-
fs/aufs/plink.c |4 ++--
fs/aufs/wkq.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/aufs/inode.c b/fs/aufs/inode.c
index af6a12a..5c2e48e 100644
--- a/fs/aufs/inode.c
+++ b/fs/aufs/inode.c
@@ -463,7 +463,7 @@ int au_test_ro(struct super_block *sb, aufs_bindex_t bindex,
int au_test_h_perm(struct inode *h_inode, int mask)
{
- if (current_fsuid() == GLOBAL_ROOT_GID)
+ if (uid_eq(current_fsuid(), GLOBAL_ROOT_UID))
return 0;
return inode_permission(h_inode, mask);
}
diff --git a/fs/aufs/plink.c b/fs/aufs/plink.c
index 0d1131b..7792680 100644
--- a/fs/aufs/plink.c
+++ b/fs/aufs/plink.c
@@ -237,7 +237,7 @@ struct dentry *au_plink_lkup(struct inode *inode,
aufs_bindex_t bindex)
h_dir = h_parent-d_inode;
tgtname.len = plink_name(a, sizeof(a), inode, bindex);
- if (current_fsuid() != GLOBAL_ROOT_GID) {
+ if (!uid_eq(current_fsuid(), GLOBAL_ROOT_UID)) {
struct au_do_plink_lkup_args args = {
.errp = h_dentry,
.tgtname= tgtname,
@@ -322,7 +322,7 @@ static int whplink(struct dentry *h_dentry, struct inode
*inode,
tgtname.len = plink_name(a, sizeof(a), inode, bindex);
/* always superio. */
- if (current_fsuid() != GLOBAL_ROOT_GID) {
+ if (!uid_eq(current_fsuid(), GLOBAL_ROOT_UID)) {
struct do_whplink_args args = {
.errp = err,
.tgt= tgtname,
diff --git a/fs/aufs/wkq.c b/fs/aufs/wkq.c
index 49b59d2..07561ca 100644
--- a/fs/aufs/wkq.c
+++ b/fs/aufs/wkq.c
@@ -46,7 +46,7 @@ static void wkq_func(struct work_struct *wk)
{
struct au_wkinfo *wkinfo = container_of(wk, struct au_wkinfo, wk);
- AuDebugOn(current_fsuid() != GLOBAL_ROOT_GID);
+ AuDebugOn(!uid_eq(current_fsuid(), GLOBAL_ROOT_UID));
AuDebugOn(rlimit(RLIMIT_FSIZE) != RLIM_INFINITY);
wkinfo-func(wkinfo-args);
signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Re: security_file_mmap locking
On Tue, 2012-07-24 at 14:23 +0900, sf...@users.sourceforge.net wrote: Ben Hutchings: If there is no lock higher than mmap_sem that might be used in this way, then there is no problem and there is also no need for using the workqueue. ?? I may be confused again. Why workqueue is unnecessary? The work item runs on *some* workqueue. ?? Do you mean aufs_mmap() can call ..._file() directly in such case, even LSM tries acquiring mmap_sem? I think it should call security_mmap_file() directly. If some LSM uses the mm context and needs to acquire mmap_sem then it will hang, but this will be an obvious failure and less bad than a quiet failure due to using the mm context of the worker thread. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Re: security_file_mmap locking
On Mon, 2012-07-23 at 12:36 +0900, sf...@users.sourceforge.net wrote: Ben Hutchings: security_mmap_addr() is called with mmap_sem held, but anyway we don't need to call it from aufs... security_mmap_addr() is called with mmap_sem held?? Which source file are you reading? do_mmap_pgoff() /* The caller must hold down_write(current-mm-mmap_sem) */ - get_unmapped_area() - security_mmap_addr() sys_brk() - down_write(mm-mmap_sem); - do_brk() - get_unmapped_area() - security_mmap_addr() __get_user_pages() /* Must be called with mmap_sem held for read or write */ - find_extend_vma() - expand_stack() - expand_downwards() - security_mmap_addr() Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp signature.asc Description: This is a digitally signed message part -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Re: security_file_mmap locking
On Mon, 2012-07-23 at 21:26 +0900, sf...@users.sourceforge.net wrote: Ben Hutchings: do_mmap_pgoff() /* The caller must hold down_write(current-mm-mmap_sem) = */ - get_unmapped_area() - security_mmap_addr() ::: Thanks. And I am sorry. I was confused. I have to correct the orders of security_mmap_addr() and ..._file() and mmap_sem, which is ..._file() is called BEFORE mmap_sem and .._addr() is AFTER. But the conclusion about the ..._file() call in aufs_mmap() is unchanged. As long as ..._file() should be called out of mmap_sem, delegating to kworker is necessary I think. If the LSM mmap_addr callback needs to acquire mmap_sem then it will be using the wrong mm context, so this doesn't fix the problem. If it needs to acquire a lock that's higher in the lock hierarchy than mmap_sem then I think an AB-BA deadlock is still possible. Given two threads in the same process: Thread 1 Thread 2 kworker - mmap() acquire L acquire mmap_sem acquire mmap_sem [blocked] schedule work wait for work [blocked] security_mmap_file() acquire L [blocked] If there is no lock higher than mmap_sem that might be used in this way, then there is no problem and there is also no need for using the workqueue. Do you have any other better approach? Or do you think it is good to modify mm/*.c? Ugh... Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp signature.asc Description: This is a digitally signed message part -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Re: security_file_mmap locking
On Mon, Jul 23, 2012 at 10:36:21PM +0900, sf...@users.sourceforge.net wrote: Ben Hutchings: If the LSM mmap_addr callback needs to acquire mmap_sem then it will be using the wrong mm context, so this doesn't fix the problem. If it LSM mmap_addr()? _file()? Gah, of course I meant mmap_file here! If you mean _addr() acquires mmap_sem, then it means a simple problem of LSM. Let's make it sure again together. _addr() is protected by mmap_sem. :-) If you mean _file() (instead of _addr), hmm... it may be possible. Thinking over why security_mmap_file() is splitted into _addr() and _file(), if I remember correctly, all tasks which requires mmap_sem should goes to _addr(), and this is the main reason of splitting. But some exotic LSM module may try such breakage (I know we are talking on If ...). Even such case, I don't think it causes a problem since mmap_sem is per task object. But why would it try to acquire mmap_sem, if not to manipulate the mm of the task that called mmap()? In which case, it gets the wrong mm. (Actually, I think current-mm may be NULL for kernel threads. Not sure whether that's still true.) As long as aufs delegates the _file() call to kworker, the mmap_sem object which _file() tries to acquire is the korker's mmap_sem (instead of the original process). I agree with you at the point that the process context differs from the original one. But I am not sure how critical it is. In other words, I am afraid the _file() call from aufs_mmap() has less meaning, and it is just to follow the LSM protocol/manner/rule. needs to acquire a lock that's higher in the lock hierarchy than mmap_sem then I think an AB-BA deadlock is still possible. Given two threads in the same process: I think I can understand what you want to point out. Probably the fact that originally _file() doesn't expect to be called with mmap_sem held is the point. And aufs_mmap() tries calling it with faking by another thread/mmap_sem. But is such higher lock possible? At least, in LSM, it is almost impossible (or bad approach). Which hook can do it? Don't know. But whether or not it happens, I think that the work item doesn't solve anything. If there is no lock higher than mmap_sem that might be used in this way, then there is no problem and there is also no need for using the workqueue. ?? I may be confused again. Why workqueue is unnecessary? The work item runs on *some* workqueue. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Re: security_file_mmap locking
On Sun, 2012-07-22 at 17:26 +0900, sf...@users.sourceforge.net wrote: Hello Ben, Ben Hutchings: What are these changes supposed to do? commit aa29a06fd0c6113560f2c5e3e9630fe67b097ba7 Author: J. R. Okajima hooano...@yahoo.co.jp Date: Tue Jun 12 22:08:17 2012 +0900 aufs: for 3.5-rcN, new au_security_file_mmap() 1/2 commit ad02614f68494af290af54325895091917a6b7c7 Author: J. R. Okajima hooano...@yahoo.co.jp Date: Tue Jun 12 22:08:39 2012 +0900 aufs: for 3.5-rcN, call au_security_file_mmap() 2/2 Isn't the aa29a06 commit log enough for you? An earlier change for 3.5 added this comment, which was removed by the second commit above: /* todo: the locking order between mmap_sem */ /* * err =3D security_mmap_file(h_file, au_prot_conv(vma-vm_flags), * au_flag_conv(vma-vm_flags)); */ If you looked the another commit (a1d9363), the comments just before aufs_mmap() (below), and the release mails from me (below), then you might know what these commits for are. I'm sorry - how could I have missed these comments?! I was concentrating too much on the patches and not the context, I suppose. Did lockdep report that an mmap_sem and some other lock (needed by an LSM) were not taken in the usual order? If so, moving the security_mmap_file() into another thread (workqueue) won't solve the possible deadlock, though it may well hide it from lockdep. Before linux-3.5, aufs called security_file_mmap() called directly. In 3.5, security_file_mmap() is splitted into two parts as - security_mmap_addr(), which is called BEFORE acquiring mmap_sem and checks the mapping address. - security_mmap_file(), which is called AFTER acquiring mmap_sem and checks the mapping file. security_mmap_addr() is called with mmap_sem held, but anyway we don't need to call it from aufs... Since security_mmap_file() explicitly expects mmap_sem held, I moved the security_mmap_file() call to kworker. I don't know whether security_mmap_file() actulally causes a deadlock or not. This is very dirty approach (as I wrote), but it is effective. Because mmap_sem is an object per task (process or thread), the deadlock will never happen. The mmap_sem for the process is held, but the mmap_sem for the kworker is not (and it is unrelated). Don't you agree? Yes, I think you have avoided the potential deadlock, though I'm not sure. (aa29a06 commit) -- A bad approach in order to just call security_file_mmap() for the real file on branch fs from outside of 'mmap_sem'-protected region. It may be meaningless since it is done in kworker context. I really don't like this approach but I don't have another approach to call security_file_mmap(). [...] Well, now security_mmap_file() may use wrong permissions, log wrong audit messages, or kill the wrong task (the workqueue task). This is much worse than the potential deadlock (which I don't believe will be triggered by any current LSM). Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
security_file_mmap locking
What are these changes supposed to do? commit aa29a06fd0c6113560f2c5e3e9630fe67b097ba7 Author: J. R. Okajima hooano...@yahoo.co.jp Date: Tue Jun 12 22:08:17 2012 +0900 aufs: for 3.5-rcN, new au_security_file_mmap() 1/2 commit ad02614f68494af290af54325895091917a6b7c7 Author: J. R. Okajima hooano...@yahoo.co.jp Date: Tue Jun 12 22:08:39 2012 +0900 aufs: for 3.5-rcN, call au_security_file_mmap() 2/2 An earlier change for 3.5 added this comment, which was removed by the second commit above: /* todo: the locking order between mmap_sem */ /* * err = security_mmap_file(h_file, au_prot_conv(vma-vm_flags), * au_flag_conv(vma-vm_flags)); */ Did lockdep report that an mmap_sem and some other lock (needed by an LSM) were not taken in the usual order? If so, moving the security_mmap_file() into another thread (workqueue) won't solve the possible deadlock, though it may well hide it from lockdep. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Re: Update script bldchraufs - Build a chroot environment based on AUFS
On Fri, 2012-03-16 at 02:33 +0900, sf...@users.sourceforge.net wrote: Hello Robert, Robert Wotzlaw: nearly two years ago I send you the script bldchraufs. Since that time many things have changed. This concerns the Linux kernel - now the kernel is dressed with a three as major number - and the current Debian distribution of the testing domain is called Wheezy. All these ::: Yes, I remember that I put your product under aufs2-util.git/sample/auroot. The following kernel message is the output that was produced during the run of the above mentioned script: [ 99.881160] aufs: module is from the staging directory, the quality is unknown, you have been warned. I guess this message is produced by debian. Yes, we mark as aufs as 'staging' since it isn't a part of the upstream kernel. [ 99.884200] aufs 2.1-standalone.tree-3.0-rcN-20110711 Oh, no. This version is once labeled don't use. - for linux-3.x, aufs2 is called don't use. - aufs-2.1 is not supported now. - use aufs3 for linux-3.x. - if debian people made their own version of aufs, I cannot support it. [...] Neither do we; this is some old kernel package. We are using Linux 3.2 as the basis for our next stable release 'wheezy' and we currently have aufs3.2 20120109. (I suppose I should update to 20120312?) Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt
On Mon, 2012-01-02 at 11:58 +0900, sf...@users.sourceforge.net wrote: Thorsten Glaser: It introduces a new separated file include/linux/aufs_name.h. Isn=E2=80=99t that a bit overkill? Hmm, I may have to agree with that. Honestly speaking, I don't like this approach. But embedding (expanding) AUFS_NAME is worse for me. Why, how often do you expect to change AUFS_NAME? [...] So I still think it is better to define it in Makefile. If I remove refering the current macro in the definition, then the life will be easier, but it is still useful and I want to keep it. Additonally it is not a essential problem I think. Finally I'd like to add sched.h between aufs_name and pr_fmt (see the attached patch). How do you think? I think it would be much better to put this in fs/aufs/aufs.h and make each of fs/aufs/*.c include that first. J. R. Okajima --- a/fs/aufs/Makefile +++ b/fs/aufs/Makefile @@ -10,6 +10,7 @@ endif ccflags-y += -DDEBUG # sparse doesn't allow spaces ccflags-y += -imacros linux/aufs_name.h +ccflags-y += -include linux/sched.h ccflags-y += -D'pr_fmt(fmt)=AUFS_NAME\040%s:%d:%s[%d]:\040fmt,__func__,__LINE__,current-comm,current-pid' obj-$(CONFIG_AUFS_FS) += aufs.o The comment about sparse belongs immediately before the definition of pr_fmt. Ben. -- Ben Hutchings All the simple programs have been written, and all the good names taken. signature.asc Description: This is a digitally signed message part -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
[PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt
AUFS_NAME is only defined in aufs_type.h but pr_fmt may be used in
headers included before aufs_type.h.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
This should fix the build failure reported in
http://lists.debian.org/debian-kernel/2011/12/msg00460.html.
An alternative change was proposed in
http://lists.debian.org/debian-kernel/2011/12/msg00482.html.
Ben.
fs/aufs/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/aufs/Makefile b/fs/aufs/Makefile
index 58ad988..9594b8a 100644
--- a/fs/aufs/Makefile
+++ b/fs/aufs/Makefile
@@ -5,7 +5,7 @@ include ${srctree}/${src}/magic.mk
# enable pr_debug
ccflags-y += -DDEBUG
# sparse doesn't allow spaces
-ccflags-y +=
-D'pr_fmt(fmt)=AUFS_NAME\040%s:%d:%s[%d]:\040fmt,__func__,__LINE__,current-comm,current-pid'
+ccflags-y +=
-D'pr_fmt(fmt)=aufs\040%s:%d:%s[%d]:\040fmt,__func__,__LINE__,current-comm,current-pid'
obj-$(CONFIG_AUFS_FS) += aufs.o
aufs-y := module.o sbinfo.o super.o branch.o xino.o sysaufs.o opts.o \
--
1.7.7.3
signature.asc
Description: This is a digitally signed message part
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
Re: Squeeze on USB
On Mon, 2011-11-21 at 09:18 +0900, sf...@users.sourceforge.net wrote: Hello tovis, tovis: I have read man, aufs html documentation but I have still do not understand how to construct the command for making ro /var to be a unified with /tmp/var wr so in result every files in /var are seen by system but writes to /var goes to ramdisk/tmpfs ... Generally you can do it by # mount -t aufs -o br:/tmp/var:/var none /var Should I make a separate ram disk (different from /tmp which is tmpfs)? What the correct syntax for this branch(?). Can I put it to fstab? Should I built a new initrd? - you can use any dir as an aufs branch (as long as it doesn't make a loop with another branch). So you don't have to make a separate ramdisk. - you can write an aufs entry in your fstab if you want - for initrd, it is totally up to + what your initrd does + what you want to do + when your /var is mounted + etc. but generally, if you want to use aufs for /var only, then the above command should be enough. I'd suggest you to check the aufs version in your debian system, since it is known that aufs in debian is obsolete. I should note that aufs is included in the Debian kernel only to support the Debian Live system. So far as I know, it does work well enough for that. Debian unstable generally has the current version of aufs (old versions usually won't compile due to VFS changes). Also aufs doesn't support linux-2.6.32 anymore. If you want to use aufs on linux-2.6.32, then I'd suggest you to get the last version of aufs2.1-32. If there are important bug fixes that aren't in Debian 6.0 (squeeze) then please inform debian-l...@lists.debian.org, debian-ker...@lists.debian.org. The current version in squeeze is based on: commit a7f3024fe756f2ad59af8520e573c79220a73839 Author: J. R. Okajima hooano...@yahoo.co.jp Date: Sun Jan 24 01:16:45 2010 +0900 aufs2 standalone version for linux-2.6.32 with the following fixes cherry-picked from aufs2-2.6: commit e62ca9737674cf9b70a961cb8d1efed4a7cff976 Author: J. R. Okajima hooano...@yahoo.co.jp Date: Mon Mar 1 17:52:50 2010 +0900 Revert aufs: narrow down the BKL region commit 639e607997502dfe7dbe140c8de5d81ba99d4240 Author: J. R. Okajima hooano...@yahoo.co.jp Date: Mon Mar 1 23:13:34 2010 +0900 Revert aufs: bugfix, unlock mmap_sem temporary using BKL commit d986fa5a8557f6861fcac4106b6d75301bf5d118 Author: J. R. Okajima hooano...@yahoo.co.jp Date: Mon Mar 8 23:45:56 2010 +0900 aufs: bugfix, another approach to keep the lock order of mmap_sem commit b0372e021a903e33f39dd515ceebd8506b1c52aa Author: J. R. Okajima hooano...@yahoo.co.jp Date: Tue Jun 29 14:32:26 2010 +0900 aufs: bugfix, separate the workqueue for preprocessing mmap Note again, aufs2.1 is not maintained now. Fair enough. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
Re: Squeeze on USB
On Mon, 2011-11-21 at 14:02 +0900, sf...@users.sourceforge.net wrote: (While I don't know this mail is delivered expectedly, I am sending to debian-live and debian-kernel ML too since Ben Hutchings requested me to do so. Note that aufs-users ML is members only and your reply may be rejected.) Hello Ben, Ben Hutchings: If there are important bug fixes that aren't in Debian 6.0 (squeeze) then please inform debian-l...@lists.debian.org, debian-ker...@lists.debian.org. The current version in squeeze is based on: Ok, On debian squeeze, /lib/modules/2.6.32-5-686/kernel/fs/aufs/aufs.ko shows 2-standalone.tree-32-20100125 as its version. There are many commits in aufs2-2.6.git#aufs2.1-32 after 2010/01/25. You may not want to see all 312 commits, so I'd try pick some of them which looks important by dropping the commits which titled as tiny or minor. There still exist about 150 commits. [...] I was hoping you would be able to identify the most important fixes, dealing with data loss and security bugs. This long list of changes appears to include cleanup and new features, which would not be acceptable in a update to a stable release. (The only new features allowed are for supporting new hardware.) I understand if you don't want to spend time doing that for what you consider an obsolete release, but if you can then it would really be appreciated. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
