Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1225530 > unrolled thread

First kernel patch (optimization)

Back to article view | Back to linux.kernel

Contents

  First kernel patch (optimization) Eric Curtin <ericcurtin17@gmail.com> - 2015-09-15 22:00 +0200
    Re: First kernel patch (optimization) Felipe Balbi <balbi@ti.com> - 2015-09-15 22:20 +0200
    Re: First kernel patch (optimization) Steve Calfee <stevecalfee@gmail.com> - 2015-09-16 02:10 +0200
      Re: First kernel patch (optimization) Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-16 13:50 +0200
        RE: First kernel patch (optimization) David Laight <David.Laight@ACULAB.COM> - 2015-09-16 15:00 +0200
          Re: First kernel patch (optimization) Jaime Arrocha <jarr@innercoder.com> - 2015-09-17 04:10 +0200
            RE: First kernel patch (optimization) David Laight <David.Laight@ACULAB.COM> - 2015-09-17 10:50 +0200
        Re: First kernel patch (optimization) Greg KH <gregkh@linuxfoundation.org> - 2015-09-16 15:40 +0200
          Re: First kernel patch (optimization) Eric Curtin <ericcurtin17@gmail.com> - 2015-09-16 18:10 +0200
            Re: First kernel patch (optimization) Theodore Ts'o <tytso@mit.edu> - 2015-09-16 18:50 +0200
              Re: First kernel patch (optimization) Raymond Jennings <shentino@gmail.com> - 2015-09-16 19:30 +0200
              Re: First kernel patch (optimization) Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-16 19:30 +0200
                Re: First kernel patch (optimization) Theodore Ts'o <tytso@mit.edu> - 2015-09-18 05:20 +0200
                  Re: First kernel patch (optimization) Greg KH <gregkh@linuxfoundation.org> - 2015-09-18 09:50 +0200
                    Re: First kernel patch (optimization) Raymond Jennings <shentino@gmail.com> - 2015-09-18 11:40 +0200
                      Re: First kernel patch (optimization) Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-18 21:10 +0200
                    Re: First kernel patch (optimization) Theodore Ts'o <tytso@mit.edu> - 2015-09-19 04:30 +0200
                      Re: First kernel patch (optimization) Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-19 06:30 +0200
                      Re: First kernel patch (optimization) Greg KH <gregkh@linuxfoundation.org> - 2015-09-19 07:20 +0200
                        Re: First kernel patch (optimization) Theodore Ts'o <tytso@mit.edu> - 2015-09-19 14:30 +0200
                        Re: First kernel patch (optimization) Alexander Holler <holler@ahsoftware.de> - 2015-09-19 15:00 +0200
                          Re: First kernel patch (optimization) Alexander Holler <holler@ahsoftware.de> - 2015-09-19 16:20 +0200
                          Re: First kernel patch (optimization) Theodore Ts'o <tytso@mit.edu> - 2015-09-19 16:30 +0200
                            Re: First kernel patch (optimization) Alexander Holler <holler@ahsoftware.de> - 2015-09-19 19:50 +0200
                              Re: First kernel patch (optimization) Theodore Ts'o <tytso@mit.edu> - 2015-09-20 04:30 +0200
                                Re: First kernel patch (optimization) Alexander Holler <holler@ahsoftware.de> - 2015-09-20 12:50 +0200
                                  Re: First kernel patch (optimization) Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-21 17:50 +0200
                                    Re: First kernel patch (optimization) Alexander Holler <holler@ahsoftware.de> - 2015-09-21 19:30 +0200
                                    Re: First kernel patch (optimization) Alexander Holler <holler@ahsoftware.de> - 2015-09-21 20:50 +0200
            Re: First kernel patch (optimization) Greg KH <gregkh@linuxfoundation.org> - 2015-09-16 22:10 +0200
              Re: First kernel patch (optimization) Eric Curtin <ericcurtin17@gmail.com> - 2015-09-16 22:30 +0200
                Re: First kernel patch (optimization) Greg KH <gregkh@linuxfoundation.org> - 2015-09-17 00:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1228437

Am 19.09.2015 um 07:18 schrieb Greg KH:

> I have been saying for years that we have a lack of real projects /
> tasks / ideas for people who are skilled, yet have no idea what to do.
> I know of well over a hundred people I have email addresses of that have
> asked me for these types of things, and have patches in the kernel that
> are non-trivial to prove that they have the skill to do real things.
>
> It's a real problem, and one that I don't have an answer for.  We need
> these types of tasks, and I don't have them, and every maintainer I ask
> about it also doesn't have them.  What we are asking for is people to
> somehow come up with tasks on their own, as if they know what needs to
> be done.

I've recently posted a proof of concept for wiping files, or in other 
words to really delete files, And it was a disaster because if someone 
posts imperfect pathhes on this list, people have fun trying to eat you 
(because they seem bored or whatever).

Even posting perfect patches is a game, because there exists always a 
space, newline or variable name which might be used to start annoying 
discussions.

So, there is no reason to wonder about the lack of such tasks.

So even if you don't agree, here as task: wipe files in real. ;)

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228449

Am 19.09.2015 um 14:52 schrieb Alexander Holler:
> Am 19.09.2015 um 07:18 schrieb Greg KH:
>
>> I have been saying for years that we have a lack of real projects /
>> tasks / ideas for people who are skilled, yet have no idea what to do.
>> I know of well over a hundred people I have email addresses of that have
>> asked me for these types of things, and have patches in the kernel that
>> are non-trivial to prove that they have the skill to do real things.
>>
>> It's a real problem, and one that I don't have an answer for.  We need
>> these types of tasks, and I don't have them, and every maintainer I ask
>> about it also doesn't have them.  What we are asking for is people to
>> somehow come up with tasks on their own, as if they know what needs to
>> be done.
>
> I've recently posted a proof of concept for wiping files, or in other
> words to really delete files, And it was a disaster because if someone
> posts imperfect pathhes on this list, people have fun trying to eat you
> (because they seem bored or whatever).
>
> Even posting perfect patches is a game, because there exists always a
> space, newline or variable name which might be used to start annoying
> discussions.
>
> So, there is no reason to wonder about the lack of such tasks.
>
> So even if you don't agree, here as task: wipe files in real. ;)

By the way, in that discussion (about wiping files) I was blamed for 
writing bugs in bugzilla without offering a patch, for something they 
believe it is a feature (whereas I still believe it is a bug to not 
really delete files). That leaded me to the question if there is 
somewhere a feature request tracker, for which I've got, of course, no 
answer.

So, if there is a lack of real projects / tasks / ideas, maybe it might 
make sense to setup such a feature request tracker (or idea pool), maybe 
with the possibility to let people up/down vote ideas.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228450

On Sat, Sep 19, 2015 at 02:52:06PM +0200, Alexander Holler wrote:
> 
> I've recently posted a proof of concept for wiping files, or in other words
> to really delete files, And it was a disaster because if someone posts
> imperfect pathhes on this list, people have fun trying to eat you (because
> they seem bored or whatever).

People gave you feedback on how what would be necessary to make the
patch acceptable, and you rejected the advice complaining that it
would take you months of "unpaid time".  You were then complaining
that the people who gave you feedback wouldn't fix the patch for you,
and that you threatened that if we didn't integrate your racy patch
into the core VFS, you would go switch to FreeBSD.

> Even posting perfect patches is a game, because there exists always a space,
> newline or variable name which might be used to start annoying discussions.

Trust me, the issues with your patch went *way* beyond extra spaces or
newlines.

> So, there is no reason to wonder about the lack of such tasks.

Greg was specifically looking for patches that could be done in a
weekend.

If you want to raise the argument that we should lower the standards
for accepting patches so that more patches can accomplished within a
weekend's worth of work, we can have that discussion --- but I'm not
sure it will have the end result that you are hoping for.

Best regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228564

Am 19.09.2015 um 16:22 schrieb Theodore Ts'o:
> On Sat, Sep 19, 2015 at 02:52:06PM +0200, Alexander Holler wrote:
>>
>> I've recently posted a proof of concept for wiping files, or in other words
>> to really delete files, And it was a disaster because if someone posts
>> imperfect pathhes on this list, people have fun trying to eat you (because
>> they seem bored or whatever).
>
> People gave you feedback on how what would be necessary to make the
> patch acceptable, and you rejected the advice complaining that it
> would take you months of "unpaid time".  You were then complaining
> that the people who gave you feedback wouldn't fix the patch for you,
> and that you threatened that if we didn't integrate your racy patch
> into the core VFS, you would go switch to FreeBSD.

Sorry, but I can happily live without feedback like "charming".

I've complained about the requirement to post perfect patches without 
even the promise that they will ever have a chance to end up in the 
kernel. But where should someone get such an OK for an idea without the 
possibility to post preliminary patches without earning insulting comments?

Anyway, I've accepted that I'm the error here which is why I almost 
don't post any patches here anymore.

>> Even posting perfect patches is a game, because there exists always a space,
>> newline or variable name which might be used to start annoying discussions.
>
> Trust me, the issues with your patch went *way* beyond extra spaces or
> newlines.

It was (and is, imho) a working proof of concept. I've posted the patch 
to describe the idea, and NOT as a perfect patch ready for inclusion. 
I'm fully aware that there are million reasons why some parts of a file 
might not be deleted, but that is a matter how you describe the 
functionality. And the concept works imho for many use cases. At least 
much, much, much better than just nothing.

But obviously, one of biggest failures one can do, is to post imperfect 
patches on this list. Regardless how you describe or mark them (mine had 
a RFC and WIP in front of), people will use every small detail against 
you, in order to have something to criticise or to make some fun of.

>> So, there is no reason to wonder about the lack of such tasks.
>
> Greg was specifically looking for patches that could be done in a
> weekend.

Sorry, I've missed that detail. So maybe create a tracker for such 
weekend-tasks.

> If you want to raise the argument that we should lower the standards
> for accepting patches so that more patches can accomplished within a
> weekend's worth of work, we can have that discussion --- but I'm not
> sure it will have the end result that you are hoping for.

No. I don't want to lower the standards. Maybe in regard to silly style 
stuff, but not in regard to code quality (and I mean real bugs like 
races, deadlocks or such, and not if a line has more than 80 
characters). I would have liked some comments like "good or bad idea" 
but this list is imho the wrong place to search for such useful 
comments. I haven't searched for comments on the code, as I was FULLY 
aware that the code is ugly and NOT ready for inclusion),

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228811

On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote:
> No. I don't want to lower the standards. Maybe in regard to silly style
> stuff, but not in regard to code quality (and I mean real bugs like races,
> deadlocks or such, and not if a line has more than 80 characters). I would
> have liked some comments like "good or bad idea" but this list is imho the
> wrong place to search for such useful comments. I haven't searched for
> comments on the code, as I was FULLY aware that the code is ugly and NOT
> ready for inclusion),

That was asked and answered on the original thread, but perhaps it got
lost amongst some of the noise --- some of which was contributed by
yourself, but be that as it may.

The *feature* is in and of itself not an insane idea.  "Secure delete"
is something that Linux has had before (in fact I did the original
implementation for ext2 a decade+ ago), and indeed the interface,
using the FS_SECRM_FL flag, is still present in Linux even if it is
not supported by any of the file systems in the tree at the moment.
It got ripped out because doing it right in the face of ongoing
interface changes and performance improvements (going back to the
pre-2.0, and possibly the pre-1.2 days), it was simpler to rip it out
rather than to reimplement it.

I wasn't responsible for ripping it out, back in mists of pre-history,
but I didn't care enough to reimplement it --- or complain about it,
either.  And no one else cared enough to complain to Linus about this
being a user-visible change that broke them.  So it's a great example
of how a feature and functionality that no one cares about *can* get
ripped out of the kernel.

Perhaps not so surprisingly, over a decade later, it is not currently
at the top of the priority list of any of the current file system or
VFS developers, as far as I know.  One of the reasons for that is that
there are a number of other ways of achieving the same functionality.
These include using tmpfs, or using file system level encryption.
They require a bit more system administrator setup than just being
able to set the FS_SECR_FL flag, true, but just because it's more
convenient doesn't mean that it's worth doing.

So.... this is a feature request.  It's a reasonable feature request,
in that if someone would like to pay $$$ for some consultant to
implement it in a way that is bug-free, I suspect it could go
upstream.  Someone who was very motivated and with the sufficient
skills could also invest their own effort to make a patch that can go
upstream too.  You've elected not, to because you believe it would
take you months of "unpaid time".  That's purely within your rights to
do.  But you don't have the right to try to tell other people what
work to do on their behalf --- not unless you are paying their salary.


And of course, if you want to maintain an out-of-tree patch, there's
nothing wrong with that.  I've implemented code that has never gone
upstream because the weight of the other file system developers were
afraid that Enterise Linux customers would use the feature
incorrectly, and it would cause potentially cause a security failure
if used inappropriately, which would be a PR and support nightmare for
them.

Seeing that the weight of the other file system developers are against
the patch, it's never gone into the mainline Linux kernel, even though
I could have forced the feature into ext4.  However, this patch is in
active use in practically every single data center kernel for Google,
and it's in use in at least one other very large publically traded
company that uses cluster file systems such as Hadoopfs.  And if
someone wants a copy of the FALLOC_FL_NO_HIDE_STALE patch for ext4,
I'm happy to give it to them.  But it hasn't gone upstream, and I'm OK
with that.

As far as what you want to do next, you have a personal "proof of
concept" patch that seems to work well enough for you.  Great!  I'm
sure you can keep using it for your own purposes.  If you can convince
someone with the skills to get the patch to an upstreamable state, it
is my judgement that this is doable, so this puts your feature in a
much better state than the FALLOC_FL_NO_HIDE_STALE flag.  However,
there is still a non-trivial amount of work left to do to turn your
"proof of concept" patch into something that is upstremable, including
changing the interface to using the FS_SECRM_FL flag.  And your
whining that other people should change *their* priorities to match
*yours* is not likely to help.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228867

Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:
> On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote:

> Perhaps not so surprisingly, over a decade later, it is not currently
> at the top of the priority list of any of the current file system or
> VFS developers, as far as I know.  One of the reasons for that is that
> there are a number of other ways of achieving the same functionality.
> These include using tmpfs, or using file system level encryption.
> They require a bit more system administrator setup than just being
> able to set the FS_SECR_FL flag, true, but just because it's more
> convenient doesn't mean that it's worth doing.

Again, I don't think that encryption is an alternative. Besides that 
there is always the thread that strong encrytion will become regulated, 
there is also the very real thread that someone might end up in jail 
when using encryption and throwing away the key to delete stuff. E.g., 
as to my knowledge, in the UK you might end up in jail if you don't hand 
out a password. So what happens if you've deleted the key and are really 
unable to hand it out and the people which have an interest in what 
you've once stored don't believe you?

> So.... this is a feature request.  It's a reasonable feature request,
> in that if someone would like to pay $$$ for some consultant to
> implement it in a way that is bug-free, I suspect it could go
> upstream.  Someone who was very motivated and with the sufficient
> skills could also invest their own effort to make a patch that can go
> upstream too.  You've elected not, to because you believe it would
> take you months of "unpaid time".  That's purely within your rights to
> do.  But you don't have the right to try to tell other people what
> work to do on their behalf --- not unless you are paying their salary.

First I haven't request that someone implements it for me. Besides that 
what you're describing is what maintainers do all the time. Of course, 
it's their job to request quality, but, in my humble opinion, very often 
they are requesting stuff just to request something.

And that "month of unpaid time" was for sure a cynical exaggeration I've 
done while having been angry. In fact I believe the way I've outlined 
with the ugly code (proof of concept) could be implemented by someone 
like you in a weekend. For me it needs quiet some more time because I 
had and still have almost zero knowledge about all locks and whatever 
else is used in the filesystem code. But nevertheless I was able to fix 
up a lot of stuff during another afternoon. E.g. I've added checks if a 
file is in use or if AT_WIPE was called on a directory and then returned 
errors in those cases. Unfortunately the code changed in 4.2 and that 
patch doesn't apply anymore and now, because I don't really need those 
implementation details (I'm aware of the problems of my patch), I've 
thrown the patch into the waste bin. Besides that my concept doesn't 
work on BTRFS what I'm currently using for various reasons (mainly 
compression) on most of my systems. And I have no idea if it ever will 
(because I don't know why discard on BTRFS doesn't really discard what I 
think it should discard. ;) ).


> Seeing that the weight of the other file system developers are against
> the patch, it's never gone into the mainline Linux kernel, even though
> I could have forced the feature into ext4.  However, this patch is in
> active use in practically every single data center kernel for Google,
> and it's in use in at least one other very large publically traded
> company that uses cluster file systems such as Hadoopfs.  And if
> someone wants a copy of the FALLOC_FL_NO_HIDE_STALE patch for ext4,
> I'm happy to give it to them.  But it hasn't gone upstream, and I'm OK
> with that.

Sure, but please don't forget its quiet some difference if someone does 
stuff without being paid and all he earns are unfriendly comments. In 
fact I still don't care much about if any code from me ends up in 
mainline, but I dislike quiet a lot the tone used by many maintainers to 
refuse things someone offered in a good believe.

E.g. recently I've read that a maintainer requested that patch posters 
should be aware of his calendar (like conferences he visits, merge 
windows he has to care for and similar stuff. ?!?

> As far as what you want to do next, you have a personal "proof of
> concept" patch that seems to work well enough for you.  Great!  I'm
> sure you can keep using it for your own purposes.  If you can convince
> someone with the skills to get the patch to an upstreamable state, it
> is my judgement that this is doable, so this puts your feature in a
> much better state than the FALLOC_FL_NO_HIDE_STALE flag.  However,
> there is still a non-trivial amount of work left to do to turn your
> "proof of concept" patch into something that is upstremable, including
> changing the interface to using the FS_SECRM_FL flag.  And your
> whining that other people should change *their* priorities to match
> *yours* is not likely to help.

Besides that I have absolutely no knowledge about 
FALLOC_FL_NO_HIDE_STALE or the FS_SECRM_FL flag, I've never whined. I've 
complained about the tone very often used on this list. And it doesn't 
help if you are suggesting I'm whining. It just proves my assumption, at 
least in my eyes.

Thanks for the discussion.

Alexander Holler

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229497

[Multipart message — attachments visible in raw view] — view raw

On 2015-09-20 06:41, Alexander Holler wrote:
> Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:
>> On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote:
>
>> Perhaps not so surprisingly, over a decade later, it is not currently
>> at the top of the priority list of any of the current file system or
>> VFS developers, as far as I know.  One of the reasons for that is that
>> there are a number of other ways of achieving the same functionality.
>> These include using tmpfs, or using file system level encryption.
>> They require a bit more system administrator setup than just being
>> able to set the FS_SECR_FL flag, true, but just because it's more
>> convenient doesn't mean that it's worth doing.
>
> Again, I don't think that encryption is an alternative. Besides that
> there is always the thread that strong encrytion will become regulated,
> there is also the very real thread that someone might end up in jail
> when using encryption and throwing away the key to delete stuff. E.g.,
> as to my knowledge, in the UK you might end up in jail if you don't hand
> out a password. So what happens if you've deleted the key and are really
> unable to hand it out and the people which have an interest in what
> you've once stored don't believe you?
First off, this is why I will never live in the UK.  Secondly, this is 
why if it's something that you don't want to store for a long time (that 
is, longer than the system will be powered on), you use an ephemeral 
encryption key.  Thirdly, if there is some chance you can lose the key, 
you make a secure backup (or do like I do and algorithmically generate 
passwords/encryption keys in a reproducible manner (which is itself 
secure if you do it right, and of course tell no-one the algorithm you 
use to generate them)).
>> So.... this is a feature request.  It's a reasonable feature request,
>> in that if someone would like to pay $$$ for some consultant to
>> implement it in a way that is bug-free, I suspect it could go
>> upstream.  Someone who was very motivated and with the sufficient
>> skills could also invest their own effort to make a patch that can go
>> upstream too.  You've elected not, to because you believe it would
>> take you months of "unpaid time".  That's purely within your rights to
>> do.  But you don't have the right to try to tell other people what
>> work to do on their behalf --- not unless you are paying their salary.
>
> First I haven't request that someone implements it for me. Besides that
> what you're describing is what maintainers do all the time. Of course,
> it's their job to request quality, but, in my humble opinion, very often
> they are requesting stuff just to request something.
The problem I see with this argument is:
1. There's a lot of code in the kernel that wouldn't be merged today in 
the state it's in, this creates a false sense of what quality is 
expected for new code (BTRFS in particular comes to mind here).
2. If the code can be proven to be racy, you fix it, period.  Adding 
known racy code to the kernel should never happen.  The same goes for 
unsafe usage of locking, RCU, or any subsystem related macros/functions. 
  This should probably be better spelled out in SubmittingPatches.
3. Subsystem maintainers became maintainers because they have a very 
high degree of knowledge relating to that subsystem, and usually about 
general kernel programming as well.  If a maintainer is asking you to 
fix something in your patch, I'd be more than willing to bet that they 
are right in asking you to fix it.
> And that "month of unpaid time" was for sure a cynical exaggeration I've
> done while having been angry. In fact I believe the way I've outlined
> with the ugly code (proof of concept) could be implemented by someone
> like you in a weekend. For me it needs quiet some more time because I
> had and still have almost zero knowledge about all locks and whatever
> else is used in the filesystem code. But nevertheless I was able to fix
> up a lot of stuff during another afternoon. E.g. I've added checks if a
> file is in use or if AT_WIPE was called on a directory and then returned
> errors in those cases. Unfortunately the code changed in 4.2 and that
> patch doesn't apply anymore and now, because I don't really need those
> implementation details (I'm aware of the problems of my patch), I've
> thrown the patch into the waste bin. Besides that my concept doesn't
> work on BTRFS what I'm currently using for various reasons (mainly
> compression) on most of my systems. And I have no idea if it ever will
> (because I don't know why discard on BTRFS doesn't really discard what I
> think it should discard. ;) ).
Discard has never really worked properly in BTRFS, although it is being 
worked on.  If you actually care about security though, you shouldn't be 
using discard except when re-provisioning your storage (there are 
numerous papers about why on the web), trying to use that for secure 
deletion is creating a false sense of security.

If you're using in-line compression, then that at least means that it 
will take somewhat more effort to get a file off of the disk that has 
been deleted.

[toc] | [prev] | [next] | [standalone]

#1229592

Am 21.09.2015 um 17:47 schrieb Austin S Hemmelgarn:

> The problem I see with this argument is:
> 1. There's a lot of code in the kernel that wouldn't be merged today in
> the state it's in, this creates a false sense of what quality is
> expected for new code (BTRFS in particular comes to mind here).

Just to say it a last time, THE CODE I'VE POSTED WAS NEVER MEANT FOR 
MERGING in that state. Regardless how many people will still come by and 
repeat that it was ugly, bad and broken to just use that as an 
additional argument against me.

I've absolutely no idea how you all start to test an idea and 
demonstrate it others, but I don't waste time on such tasks with looking 
for style, (premature) optimization or even races.

I know how write production ready code, doing such since a long time and 
I know how much time that costs, and I know that only fools (or students 
which have to show that they can write good code) spend this time for 
code which might end up in the waste bin anyway.

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229645

Am 21.09.2015 um 17:47 schrieb Austin S Hemmelgarn:
> On 2015-09-20 06:41, Alexander Holler wrote:
>> Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:
>>> On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote:

>>
>> Again, I don't think that encryption is an alternative. Besides that
>> there is always the thread that strong encrytion will become regulated,
>> there is also the very real thread that someone might end up in jail
>> when using encryption and throwing away the key to delete stuff. E.g.,
>> as to my knowledge, in the UK you might end up in jail if you don't hand
>> out a password. So what happens if you've deleted the key and are really
>> unable to hand it out and the people which have an interest in what
>> you've once stored don't believe you?
> First off, this is why I will never live in the UK.  Secondly, this is

(First, it should, of course, read threat, not thread, my English 
becomes worse when I'm getting angry, besides that I was working on a 
problem with threads just before.)

Just in case of, I have not used the UK as an example because I might 
hate it or similar (nothing of that is the case). I've used the UK as an 
example to make it clear that such can happen in every country (besides 
that I know that some kernel maintainers live there).. And e.g. the US 
has had a time with regulated encryption (and I think there recently was 
another attempt to regulate it again). And besides states, there might 
be other people which might getting some unwanted ideas if they might 
believe that there is something of value for them encrypted somewhere by 
you. So, in my humble opinion, it's always better to get rid of 
something clearly. That also helps against the problem that the 
encryption used today, might be worthless tomorrow.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1226438

On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
> Hi Greg,
> 
> As I said in the subject of the mail (which I have been since told I
> shouldn't have done this), I'm a noob to kernel code. I tried to pick
> off something super simple to just see what the process of getting a
> patch in is. Youtube videos and documentation only get you so far.
> 
> >From reading your response, should I refrain from sending in these
> micro-optimizations in future? Getting in smaller patches is easier
> for me as I only do this in my spare time, which I don't have a lot
> of!

micro-optimizations are great, if you can actually measure them and they
matter :)

If you are looking for someplace to start, might I recommend the
drivers/staging/ directory?  I take all sorts of "basic" cleanup
patches, and there are loads of things to do in there.  Look at the
drivers/staging/*/TODO files for specific examples of what needs to be
done to get these files cleaned up and fixed properly.

Hope this helps,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1226447

On 16 September 2015 at 21:02, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
>> Hi Greg,
>>
>> As I said in the subject of the mail (which I have been since told I
>> shouldn't have done this), I'm a noob to kernel code. I tried to pick
>> off something super simple to just see what the process of getting a
>> patch in is. Youtube videos and documentation only get you so far.
>>
>> >From reading your response, should I refrain from sending in these
>> micro-optimizations in future? Getting in smaller patches is easier
>> for me as I only do this in my spare time, which I don't have a lot
>> of!
>
> micro-optimizations are great, if you can actually measure them and they
> matter :)
>
> If you are looking for someplace to start, might I recommend the
> drivers/staging/ directory?  I take all sorts of "basic" cleanup
> patches, and there are loads of things to do in there.  Look at the
> drivers/staging/*/TODO files for specific examples of what needs to be
> done to get these files cleaned up and fixed properly.
>
> Hope this helps,
>
> greg k-h

I have realized this now after reading
http://kernelnewbies.org/FirstKernelPatch, should have done a bit more
reading before I submitted something. I'm looking at the
drivers/staging/android stuff now.

Eric Curtin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1226546

On Wed, Sep 16, 2015 at 09:21:58PM +0100, Eric Curtin wrote:
> On 16 September 2015 at 21:02, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
> >> Hi Greg,
> >>
> >> As I said in the subject of the mail (which I have been since told I
> >> shouldn't have done this), I'm a noob to kernel code. I tried to pick
> >> off something super simple to just see what the process of getting a
> >> patch in is. Youtube videos and documentation only get you so far.
> >>
> >> >From reading your response, should I refrain from sending in these
> >> micro-optimizations in future? Getting in smaller patches is easier
> >> for me as I only do this in my spare time, which I don't have a lot
> >> of!
> >
> > micro-optimizations are great, if you can actually measure them and they
> > matter :)
> >
> > If you are looking for someplace to start, might I recommend the
> > drivers/staging/ directory?  I take all sorts of "basic" cleanup
> > patches, and there are loads of things to do in there.  Look at the
> > drivers/staging/*/TODO files for specific examples of what needs to be
> > done to get these files cleaned up and fixed properly.
> >
> > Hope this helps,
> >
> > greg k-h
> 
> I have realized this now after reading
> http://kernelnewbies.org/FirstKernelPatch, should have done a bit more
> reading before I submitted something. I'm looking at the
> drivers/staging/android stuff now.

The android code is all pretty "clean" right now, nothing there for
anyone who is not an Android kernel developer to do.  Parts are about to
be deleted, and others (i.e. ION), has to stay as-is while we wait for
other kernel bits to get merged (see the updated README file in
linux-next for details about that.)

So I'd recommend something else in the staging tree, android is a bit of
an exception as to why it is in that part of the kernel at the moment...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web