linux-kernel - Re: [PATCH v3 2/9] liblockdep: Wrap kernel/lockdep.c to allow usage from userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 May 2013 12:11:31 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	torvalds@...ux-foundation.org, mingo@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/9] liblockdep: Wrap kernel/lockdep.c to allow usage
 from userspace

On Fri, May 10, 2013 at 11:18:16AM +0200, Peter Zijlstra wrote:
> On Thu, May 09, 2013 at 11:58:02AM -0400, Sasha Levin wrote:
> > kernel/lockdep.c deals with validating locking scenarios for
> > various architectures supported by the kernel. There isn't
> > anything kernel specific going on in lockdep, and when we
> > compare userspace to other architectures that don't have to deal
> > with irqs such as s390, they become all too similar.
> > 
> > We wrap kernel/lockdep.c and include/linux/lockdep.h with
> > several headers which allow us to build and use lockdep from
> > userspace. We don't touch the kernel code itself which means
> > that any work done on lockdep in the kernel will automatically
> > benefit userspace lockdep as well!
> > 
> > Signed-off-by: Sasha Levin <sasha.levin@...cle.com>
> > ---
> 
> OK, this patch is a complete fail with anything not git. Please fix it so I can
> use quilt.

So I tried patch --posix; but that makes patch unhappy too:

|--- /dev/null
|+++ b/tools/lib/lockdep/Makefile
--------------------------
No file to patch.  Skipping patch.
out of 1 hunk ignored
can't find file to patch at input line 393
Perhaps you used the wrong -p or --strip option?

And while patch has a --remove-empty-files it does not recognise
--no-remove-empty-files :/

I briefly read a thread from the git mailing list where Linus and others
discussed the various weirdness around empty files and the take away was that
git would act differently by default. Because as Linus put it: "patch" is a
total piece of utterly unbelievable SH*T. 

However, aside from different behaviour I don't think its that nice git-diff
creates patches that patch cannot possibly apply right...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/