Am 15.06.2015 um 10:58 schrieb Linus Walleij:
On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler wrote:
And because you've said that "problem space is a bit convoluted" and I
disagree, here's a summary from my point of view:
1. All the necessary information (dependen
Am 12.06.2015 um 13:36 schrieb Alexander Holler:
Am 12.06.2015 um 13:19 schrieb Alexander Holler:
Am 12.06.2015 um 09:25 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler
wrote:
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
Certainly it is possible to create
Am 12.06.2015 um 13:19 schrieb Alexander Holler:
Am 12.06.2015 um 09:25 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler
wrote:
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
Certainly it is possible to create deadlocks in this scenario, but the
scope is not to
Am 12.06.2015 um 09:25 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler wrote:
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
Certainly it is possible to create deadlocks in this scenario, but the
scope is not to create an ubreakable system.
IAnd what happens if you
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 12:17 PM, Alexander Holler wrote:
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
wrote:
You would end up with the same problem of deadlocks as currently, and you
would
Am 11.06.2015 um 13:24 schrieb Alexander Holler:
> Am 11.06.2015 um 12:17 schrieb Alexander Holler:
>> Am 11.06.2015 um 10:12 schrieb Linus Walleij:
>>> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
>>> wrote:
>>>> Am 10.06.2015 um 09:30 schrieb Linu
Am 11.06.2015 um 12:17 schrieb Alexander Holler:
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
wrote:
Am 10.06.2015 um 09:30 schrieb Linus Walleij:
i2c host comes out, probes the regulator driver, regulator driver
probes and then the
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler wrote:
Am 10.06.2015 um 09:30 schrieb Linus Walleij:
i2c host comes out, probes the regulator driver, regulator driver
probes and then the regulator_get() call returns.
This requires
Am 08.06.2015 um 21:35 schrieb Ingo Molnar:
> I pointed out specific cases where a BUG_ON() is the right solution. They are
> rare. Stop misrepresenting my words.
I'm just mimicking usual kernel maintainer behaviour, like most monkeys.
Sorry.
--
To unsubscribe from this list: send the line "uns
Am 08.06.2015 um 20:14 schrieb Alexander Holler:
Am 08.06.2015 um 14:26 schrieb Enrico Weigelt, metux IT consult:
Am 04.06.2015 um 22:39 schrieb Alexander Holler:
> As it seems to have been forgotten or overread, I've mentioned in my
series of patches last year that, with a few chang
Am 08.06.2015 um 14:26 schrieb Enrico Weigelt, metux IT consult:
Am 04.06.2015 um 22:39 schrieb Alexander Holler:
> As it seems to have been forgotten or overread, I've mentioned in my
series of patches last year that, with a few changes, it's possible to
let the algorithm I
Am 08.06.2015 um 13:27 schrieb Ingo Molnar:
* Alexander Holler wrote:
I am pretty certain that Greg would have applied such a patch in an eye blink.
As you've said it, *probably*. But such a simple exit path as you're proposing
doesn't always exist. [...]
As I said it&#x
miliar in order to have a slightly chance of save log info?
Sorry, that isn't something I would propose.
Anyway, CRASH_ON didn't exist, so I only had the choice between BUG_ON
and WARN_ON, and for the latter you need a proper exit path which isn't
always easy to find. So I appreci
Am 08.06.2015 um 11:05 schrieb Ingo Molnar:
* Alexander Holler wrote:
Am 08.06.2015 um 10:08 schrieb Richard Weinberger:
On Mon, Jun 8, 2015 at 9:40 AM, Alexander Holler wrote:
Am 08.06.2015 um 09:12 schrieb Ingo Molnar:
* Linus Torvalds wrote:
Stop with the random BUG_ON
Am 08.06.2015 um 10:08 schrieb Richard Weinberger:
On Mon, Jun 8, 2015 at 9:40 AM, Alexander Holler wrote:
Am 08.06.2015 um 09:12 schrieb Ingo Molnar:
* Linus Torvalds wrote:
Stop with the random BUG_ON() additions.
Yeah, so I propose the attached patch which attempts to resist new
of BUG_ON, WARN_ON or CRASH_ON?
Regards,
Alexander Holler
Thanks,
Ingo
>
From 724052923fbae2e3a14e0b9383c89b18217d817f Mon Sep 17 00:00:00 2001
From: Ingo Molnar
Date: Mon, 8 Jun 2015 09:01:43 +0200
Subject: [PATCH] debug: Deprecate BUG_ON() use
;> basically the same issue in [0]), and have looked into ordered probing as a
>> better way of solving this than moving nodes around in the DT or playing with
>> initcall levels.
>>
>> While reading the thread [1] that Alexander Holler started with his series to
>>
got started. Besides that the
würgaround of defered init (which, btw. leads devs to supress error
messages, which is especially bad if you are searching a problem) isn't
needed anymore if you have a list of dependecies (however you get it,
I've used DT because the dependencies already are
Am 29.04.2015 um 11:46 schrieb Alexander Holler:
Am 29.04.2015 um 08:58 schrieb Tomeu Vizoso:
On 28 April 2015 at 20:17, Alexander Holler wrote:
Am 28.04.2015 um 14:49 schrieb Tomeu Vizoso:
On 25 April 2015 at 01:15, Alexander Holler
wrote:
Am 24.04.2015 um 16:47 schrieb Tomeu Vizoso
Am 29.04.2015 um 08:58 schrieb Tomeu Vizoso:
On 28 April 2015 at 20:17, Alexander Holler wrote:
Am 28.04.2015 um 14:49 schrieb Tomeu Vizoso:
On 25 April 2015 at 01:15, Alexander Holler wrote:
Am 24.04.2015 um 16:47 schrieb Tomeu Vizoso:
Hi,
while reading the thread [0] that Alexander
Am 28.04.2015 um 14:49 schrieb Tomeu Vizoso:
On 25 April 2015 at 01:15, Alexander Holler wrote:
Am 24.04.2015 um 16:47 schrieb Tomeu Vizoso:
Hi,
while reading the thread [0] that Alexander Holler started with his series to
make probing order deterministic, it occurred to me that it should
Am 24.04.2015 um 16:47 schrieb Tomeu Vizoso:
> Hi,
>
> while reading the thread [0] that Alexander Holler started with his series to
> make probing order deterministic, it occurred to me that it should be
> possible to achieve the same by probing devices as they are referen
Am 25.03.2015 um 12:15 schrieb Alexander Holler:
Am 25.03.2015 um 12:08 schrieb Greg Kroah-Hartman:
On Wed, Mar 25, 2015 at 11:58:46AM +0100, Alexander Holler wrote:
As this has been broken since 3.16, and no one has taken the time to
fix
it since then, it's not really an issue here, p
Am 25.03.2015 um 12:08 schrieb Greg Kroah-Hartman:
On Wed, Mar 25, 2015 at 11:58:46AM +0100, Alexander Holler wrote:
As this has been broken since 3.16, and no one has taken the time to fix
it since then, it's not really an issue here, people can just use 4.0 if
they want it.
Just a h
Am 25.03.2015 um 11:15 schrieb Greg Kroah-Hartman:
On Wed, Mar 25, 2015 at 10:23:27AM +0100, Alexander Holler wrote:
Am 25.03.2015 um 09:33 schrieb Greg Kroah-Hartman:
Is there a specific patch that is in Linus's tree that fixes this issue
that I should be applying to the stable tree?
Am 25.03.2015 um 09:33 schrieb Greg Kroah-Hartman:
On Tue, Mar 24, 2015 at 07:06:56PM +0100, Alexander Holler wrote:
Am 24.03.2015 um 18:58 schrieb Greg Kroah-Hartman:
On Tue, Mar 24, 2015 at 06:30:17PM +0100, Alexander Holler wrote:
Am 24.03.2015 um 16:46 schrieb Greg Kroah-Hartman:
3.19
Am 24.03.2015 um 18:58 schrieb Greg Kroah-Hartman:
On Tue, Mar 24, 2015 at 06:30:17PM +0100, Alexander Holler wrote:
Am 24.03.2015 um 16:46 schrieb Greg Kroah-Hartman:
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: Al Viro
commit
/15/5
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Am 15.03.2015 um 09:31 schrieb Alexander Holler:
Am 15.03.2015 um 09:17 schrieb Al Viro:
On Sun, Mar 15, 2015 at 07:35:20AM +0100, Alexander Holler wrote:
Umm... If I'm not misparsing what you said, you are talking about the
Glücklicherweise nicht. Vielleicht sollten wir es zur Abwech
Hmm, a year ago or so I've stumbled over the fact that the owner might
be necessary for correct entries in sysfs (that was mtd). I've no idea
if that's true here too but it might be worse to mention it.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscri
Am 15.03.2015 um 09:17 schrieb Al Viro:
On Sun, Mar 15, 2015 at 07:35:20AM +0100, Alexander Holler wrote:
Umm... If I'm not misparsing what you said, you are talking about the
Glücklicherweise nicht. Vielleicht sollten wir es zur Abwechslung mal
mit meiner bevorzugten Sprache vers
Am 15.03.2015 um 02:39 schrieb Al Viro:
> On Sun, Mar 15, 2015 at 01:39:21AM +0100, Alexander Holler wrote:
>> Am 13.03.2015 um 17:42 schrieb Al Viro:
>>> Assorted fixes around AIO on gadgetfs: leaks, use-after-free,
>>> troubles caused by ->f_op flippi
o_read()
If that patch ends up in the stable kernels (as it is marked as such),
it needs a
value = -ENOMEM
before that added "goto fail;", otherwise the return value is unitialized.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
Am 11.03.2015 um 11:29 schrieb Alexander Holler:
Am 07.03.2015 um 12:23 schrieb Alexander Holler:
In detail it's only usable once (3.19). When unmounting it throws one or
two warnings because of too much puts (kernel/module.c:963, see below).
The result is that a subsequent mount after
Am 07.03.2015 um 12:23 schrieb Alexander Holler:
In detail it's only usable once (3.19). When unmounting it throws one or
two warnings because of too much puts (kernel/module.c:963, see below).
The result is that a subsequent mount afterwards fails because the old
instance is still
Am 07.03.2015 um 21:51 schrieb Al Viro:
> On Sat, Mar 07, 2015 at 09:03:51PM +0100, Alexander Holler wrote:
>> Am 07.03.2015 um 12:23 schrieb Alexander Holler:
>>> Am 04.03.2015 um 16:31 schrieb Alan Stern:
>>>
>>>> check to see what those values actually
Am 07.03.2015 um 12:23 schrieb Alexander Holler:
> Am 04.03.2015 um 16:31 schrieb Alan Stern:
>
>> check to see what those values actually were. It's easy enough to fix
>> up, though; revised patch below.
>
> Thanks, in contrast to the patch from Al Viro that o
stance is still busy (Resource temporarily unavailable).
I haven't looked deeper into that problem up to now.
Regards,
Alexander Holler
[ 151.425966] gadgetfs: USB Gadget filesystem, version 24 Aug 2004
[ 151.479616] gadgetfs: bound to musb-hdrc driver
[ 151.781095] gadgetfs: con
Am 02.03.2015 um 11:03 schrieb Alexander Holler:
Am 07.02.2015 um 06:56 schrieb Russ Dill:
Luckily there is an easy solution out there that solves all these
problems.
As I'm curious and have forgotten to ask in my previous mail, about
which easy solution you're talking?
Am 02.03.2015 um 14:02 schrieb Alexander Holler:
Am 02.03.2015 um 12:39 schrieb Alexander Holler:
Am 02.03.2015 um 11:20 schrieb Al Viro:
On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:
On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler
wrote:
Hello.
Commit
Am 02.03.2015 um 12:39 schrieb Alexander Holler:
Am 02.03.2015 um 11:20 schrieb Al Viro:
On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:
On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler
wrote:
Hello.
Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with
3.16
Am 02.03.2015 um 11:20 schrieb Al Viro:
On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:
On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler wrote:
Hello.
Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with 3.16) broke
dynamic changing of file_operations->[r
Am 07.02.2015 um 06:56 schrieb Russ Dill:
Alexander Holler ahsoftware.de> writes:
Hello.
I've set up a repository at github which contains the 3 pathches to add
limited support to the Linux kernel for wiping files on ext4 and (v)fat
with 3 small patches and a total of "9 files
anymore.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
/wipe_lnx
Feel free to send me any comments, patches or even flames in privat
(off-list)! because I don't want to become involved in annoying
discussions here anymore.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
inside some, of course maybe uncomfortable, limits and
don't do any worse. just better.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Am 04.02.2015 um 17:45 schrieb Alexander Holler:
Am 04.02.2015 um 17:25 schrieb Lukáš Czerner:
On Wed, 4 Feb 2015, Alexander Holler wrote:
Am 04.02.2015 um 15:52 schrieb Lukáš Czerner:
On Wed, 4 Feb 2015, Alexander Holler wrote:
I'm happy for all the feedback. But it doesn't he
Am 04.02.2015 um 17:25 schrieb Lukáš Czerner:
On Wed, 4 Feb 2015, Alexander Holler wrote:
Am 04.02.2015 um 15:52 schrieb Lukáš Czerner:
On Wed, 4 Feb 2015, Alexander Holler wrote:
I'm happy for all the feedback. But it doesn't help me. I'm not going to spend
the necess
Am 04.02.2015 um 15:52 schrieb Lukáš Czerner:
> On Wed, 4 Feb 2015, Alexander Holler wrote:
>> I'm happy for all the feedback. But it doesn't help me. I'm not going to
>> spend
>> the necessary time unpaid.
>
> Right, you'd much rather have s
Am 04.02.2015 um 14:29 schrieb Alexander Holler:
Am 04.02.2015 um 14:21 schrieb Alexander Holler:
I tell you that discussions of APIs should CC linux-api, which I am
now CCing into this thread, again, because, again, you're not
listening to feedback.
Please don't confuse "not
Am 04.02.2015 um 14:21 schrieb Alexander Holler:
I tell you that discussions of APIs should CC linux-api, which I am
now CCing into this thread, again, because, again, you're not
listening to feedback.
Please don't confuse "not listening" with "unable to fulfil
Am 04.02.2015 um 14:06 schrieb Michael Kerrisk:
Alexander,
On Wed, Feb 4, 2015 at 1:22 PM, Alexander Holler wrote:
Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:
The fact is that the current patches are useless for anything other
than proof-of-concept. Now you know more that needs to be done
Am 04.02.2015 um 13:50 schrieb Alexander Holler:
Am 04.02.2015 um 13:42 schrieb Alexander Holler:
Am 04.02.2015 um 13:22 schrieb Alexander Holler:
Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:
The fact is that the current patches are useless for anything other
than proof-of-concept. Now you
Am 04.02.2015 um 13:42 schrieb Alexander Holler:
Am 04.02.2015 um 13:22 schrieb Alexander Holler:
Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:
The fact is that the current patches are useless for anything other
than proof-of-concept. Now you know more that needs to be done or
That's
Am 04.02.2015 um 13:22 schrieb Alexander Holler:
Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:
The fact is that the current patches are useless for anything other
than proof-of-concept. Now you know more that needs to be done or
That's wrong. The patches already work. If you delete a
such a simple
solution, in contrast to the the 's' bit, possible.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Am 04.02.2015 um 00:33 schrieb Al Viro:
On Tue, Feb 03, 2015 at 07:01:50PM +0100, Alexander Holler wrote:
Yeah, as I've already admitted in the bug, I never should have use
the word secure, because everyone nowadays seems to end up in panic
when reading that word.
So, if I would be ab
0x2000
in include/uapi/linux/fcntl.h
for using the old unlinkat() with that new flag. That's much easier to
handle than a new syscall which likely never will end up in the kernel
and makes my silly patches even more simple.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the
Am 03.02.2015 um 18:48 schrieb Theodore Ts'o:
On Tue, Feb 03, 2015 at 01:48:56PM +0100, Alexander Holler wrote:
E.g. my parents are stull successfully using contact lists on paper. These
are still more readable, easier to handle and smaller than any available
electronic replacement. And
Am 03.02.2015 um 16:41 schrieb Lukáš Czerner:
On Tue, 3 Feb 2015, Alexander Holler wrote:
I'm already spending a lot of time trying to convince the developers here,
that this a feature most people expect from any filesystem. And I've written
these patches, for which now, even
Am 03.02.2015 um 16:41 schrieb Lukáš Czerner:
I'll give up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.
t other people don't care for these use cases. They would be
happy if at least the most trivial cases to recover deleted contents
could be avoided.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
Am 03.02.2015 um 16:13 schrieb Alexander Holler:
Am 03.02.2015 um 15:50 schrieb Alexander Holler:
Maybe I should request removal of shred from Fedora/RH instead.
According to you it's one of the most misleading and useless tools. So
why still confuse people with it and still ship it?
Am 03.02.2015 um 15:50 schrieb Alexander Holler:
Maybe I should request removal of shred from Fedora/RH instead.
According to you it's one of the most misleading and useless tools. So
why still confuse people with it and still ship it?
At least it should be documented that it doesn
Am 03.02.2015 um 14:50 schrieb Lukáš Czerner:
On Mon, 2 Feb 2015, Alexander Holler wrote:
Date: Mon, 2 Feb 2015 18:05:11 +0100
From: Alexander Holler
To: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Alexander Holler
Subject: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s
Am 03.02.2015 um 13:48 schrieb Alexander Holler:
E.g. my parents are stull successfully using contact lists on paper.
These are still more readable, easier to handle and smaller than any
available electronic replacement. And they have absolutely no problem to
destroy an old one when they
Am 03.02.2015 um 10:23 schrieb Alexander Holler:
Or to give another more common example: If you delete your contact list,
I likely might find again by just searching for 0x6f726956 at the device
level (assuming you've stored a contact in that list with the same
surname as yours.
And, be
Am 03.02.2015 um 09:51 schrieb Alexander Holler:
Am 03.02.2015 um 08:56 schrieb Al Viro:
On Tue, Feb 03, 2015 at 07:58:50AM +0100, Alexander Holler wrote:
Charming. Now, what exactly happens if two such syscalls overlap in
time?
What do you think will happen? I assume you haven't look
Am 03.02.2015 um 08:56 schrieb Al Viro:
On Tue, Feb 03, 2015 at 07:58:50AM +0100, Alexander Holler wrote:
Charming. Now, what exactly happens if two such syscalls overlap in time?
What do you think will happen? I assume you haven't looked at how I've
implemented set_sec
Am 03.02.2015 um 09:10 schrieb Al Viro:
On Tue, Feb 03, 2015 at 09:01:36AM +0100, Alexander Holler wrote:
Am 03.02.2015 um 08:56 schrieb Al Viro:
While we are at it, "overwrite with zeroes" is too weak if the attacker
might get hold of the actual hardware. Google for details - it
Am 03.02.2015 um 08:56 schrieb Al Viro:
While we are at it, "overwrite with zeroes" is too weak if the attacker
might get hold of the actual hardware. Google for details - it's far too
long story for l-k posting. Look for data recovery and secure data erasure...
You might read
http://link.s
Am 03.02.2015 um 07:05 schrieb Al Viro:
On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote:
+ if (inode) {
+ // TODO:
+ // if (inode is file and 's' flag is set)
+ // secure = true;
+ i
Am 03.02.2015 um 07:05 schrieb Al Viro:
> On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote:
>> +if (inode) {
>> +// TODO:
>> +// if (inode is file and 's' flag is set)
>> +// secur
Signed-off-by: Alexander Holler
---
fs/ext4/ext4.h| 2 ++
fs/ext4/mballoc.c | 25 +++--
fs/ext4/super.c | 12
3 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index c55a1fa..e66507c 100644
--- a/fs/ext4/ext4.h
You have to build the new rm yourself
Signed-off-by: Alexander Holler
---
...ion-s-to-rm-to-support-unlinkat_s-current.patch | 111 +
1 file changed, 111 insertions(+)
create mode 100644
0001-WIP-Add-option-s-to-rm-to-support-unlinkat_s-current.patch
diff --git a/0001-WIP
Signed-off-by: Alexander Holler
---
fs/fat/fat.h| 1 +
fs/fat/fatent.c | 20
fs/fat/inode.c | 13 +
3 files changed, 34 insertions(+)
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index e0c4ba3..b9febda 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -81,6
Simple test, needs the new rm with option -s.
Signed-off-by: Alexander Holler
---
test_unlinkat_s.sh | 27 +++
1 file changed, 27 insertions(+)
create mode 100755 test_unlinkat_s.sh
diff --git a/test_unlinkat_s.sh b/test_unlinkat_s.sh
new file mode 100755
index 000
Signed-off-by: Alexander Holler
---
arch/x86/syscalls/syscall_32.tbl | 1 +
arch/x86/syscalls/syscall_64.tbl | 1 +
fs/namei.c| 38 ++-
include/asm-generic/audit_dir_write.h | 1 +
include/linux/fs.h| 1
f they will end up in the kernel. I already have and can use them, I'm
happy with them and I don't really need them in the official kernel as I'm
able to easily rebase them myself (thanks to git).
- Don't be disappointed because the patches are that simple. The idea
counts. ;)
Am 25.01.2015 um 11:32 schrieb Alexander Holler:
Am 25.01.2015 um 03:43 schrieb Alexander Holler:
Am 25.01.2015 um 03:13 schrieb Pádraig Brady:
On 24/01/15 12:29, Alexander Holler wrote:
Am 24.01.2015 um 13:09 schrieb Alexander Holler:
Am 24.01.2015 um 12:37 schrieb Alexander Holler:
Am
Am 27.01.2015 um 19:42 schrieb Steven Rostedt:
Hey, if you end up doing it, it could help with your resume.
Oh, young padovan, I'm writing SW since 30a and it just would make it
even longer, which already seems to be a problem for many HR people.
Alexander Holer
--
To unsubscribe from this
g a simple piece of (imho) interesting information.
Happy frameworking and sorry for disturbing.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
Am 27.01.2015 um 18:48 schrieb Steven Rostedt:
On Tue, 27 Jan 2015 18:38:36 +0100
Alexander Holler wrote:
Anyway, I like(d) Linux because it didn't had a splash screen and used
to spit out all types of information on the screen where it could be
easily seen or found (in contrast oth
that the kernel does a
lot of things. ;)
I don't want that ftrace stuff appears in dmesg, but I like to do
dmesg | grep -i mmc (or whatever is of interest)
instead of
grep -Rsi mmc /sys/ or
something like
find /sys -iname '*mmc*' -exec \;
Alexander Holler
--
To unsubscribe
ore complicated because
grep doesn't connect the file name with the content, so you need more
complicated stuff to combine both in order to search for and find
something in sysfs.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
Am 27.01.2015 um 15:21 schrieb Borislav Petkov:
On Tue, Jan 27, 2015 at 01:44:15PM +0100, Alexander Holler wrote:
Yes. Sorry, but I had so many bad experiences with maintainers.
Well, I can't comment on your experience for the simple reason that I
haven't followed those discussions
depending on config settings) instead of a
desastrous memory corruption which (hard-) reseted the machine (and
might have done even more bad things) and so on.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
Am 27.01.2015 um 13:08 schrieb Borislav Petkov:
On Tue, Jan 27, 2015 at 01:02:49PM +0100, Alexander Holler wrote:
Look at the source at the message which is printed just before and decide
which one you find more informational / useful.
I find such a message absolutely useless. Also, if it
Am 27.01.2015 um 12:55 schrieb Richard Weinberger:
On Tue, Jan 27, 2015 at 12:48 PM, Alexander Holler wrote:
It's an interesting detail, so inform the user about it.
Signed-off-by: Alexander Holler
---
drivers/mmc/core/bus.c | 4
1 file changed, 4 insertions(+)
diff --git a/dr
It's an interesting detail, so inform the user about it.
Signed-off-by: Alexander Holler
---
drivers/mmc/core/bus.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 8a1f124..4a60028 100644
--- a/drivers/mmc/core/bus.c
+++ b/dr
Am 25.01.2015 um 13:36 schrieb Alexander Holler:
Am 25.01.2015 um 13:24 schrieb Alexander Holler:
Am 25.01.2015 um 13:08 schrieb Richard Weinberger:
Or add support for the "s" chattr to major filesystems.
(...)
So maybe shred should first set the 's' attribute befo
Am 25.01.2015 um 13:28 schrieb Richard Weinberger:
Am 25.01.2015 um 13:24 schrieb Alexander Holler:
Am 25.01.2015 um 13:08 schrieb Richard Weinberger:
On Sun, Jan 25, 2015 at 12:42 PM, Alexander Holler wrote:
Now, after I ended up into flaming a lot (sorry again, but this topic made
me angry
Am 25.01.2015 um 13:24 schrieb Alexander Holler:
Am 25.01.2015 um 13:08 schrieb Richard Weinberger:
Or add support for the "s" chattr to major filesystems.
And change the manpage for the 's' attribute to change the "overwriting
with zero" with some other wordin
Am 25.01.2015 um 13:08 schrieb Richard Weinberger:
On Sun, Jan 25, 2015 at 12:42 PM, Alexander Holler wrote:
Now, after I ended up into flaming a lot (sorry again, but this topic made
me angry for so long and I had to spent too much time to get rid of unwanted
content and answering other
Am 25.01.2015 um 12:42 schrieb Alexander Holler:
Now, after I ended up into flaming a lot (sorry again, but this topic
made me angry for so long and I had to spent too much time to get rid of
unwanted content and answering other peoples question in regard to that
topic), I should offer something
but I think there isn't any
black magic involved in offering the user a simple way to really delete
files.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Am 25.01.2015 um 11:32 schrieb Alexander Holler:
So we are now at the point that the only way to keep some information
private (forever) is to not store it on any computer.
That should be written "any electronic device (including phones,
tablets, cameras, TVs and clouds)" inste
Am 25.01.2015 um 03:43 schrieb Alexander Holler:
Am 25.01.2015 um 03:13 schrieb Pádraig Brady:
On 24/01/15 12:29, Alexander Holler wrote:
Am 24.01.2015 um 13:09 schrieb Alexander Holler:
Am 24.01.2015 um 12:37 schrieb Alexander Holler:
Am 24.01.2015 um 11:45 schrieb Alexander Holler:
It
Am 25.01.2015 um 03:13 schrieb Pádraig Brady:
On 24/01/15 12:29, Alexander Holler wrote:
Am 24.01.2015 um 13:09 schrieb Alexander Holler:
Am 24.01.2015 um 12:37 schrieb Alexander Holler:
Am 24.01.2015 um 11:45 schrieb Alexander Holler:
It uses shred, in the hope it will somedays learn how
Am 24.01.2015 um 13:09 schrieb Alexander Holler:
Am 24.01.2015 um 12:37 schrieb Alexander Holler:
Am 24.01.2015 um 11:45 schrieb Alexander Holler:
It uses shred, in the hope it will somedays learn how to shred stuff on
FLASH based devices securely too, once that has become possible.
BTW
101 - 200 of 723 matches
Mail list logo
