linux-kernel - Re: [RFC PATCH 14/43] ptrace, frv: change signature of arch

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]

Message-ID: <5542.1282911123@redhat.com>
Date:	Fri, 27 Aug 2010 13:12:03 +0100
From:	David Howells <dhowells@...hat.com>
To:	Namhyung Kim <namhyung@...il.com>
Cc:	dhowells@...hat.com, Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>, Arnd Bergmann <arnd@...db.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 14/43] ptrace, frv: change signature of arch_ptrace()

Namhyung Kim <namhyung@...il.com> wrote:

> > That description means nothing.  Commit
> > f76671df26ef06321480e702770f88f61272be29 is not upstream.
> 
> Hi,
> Thank you for noticing. My bad.

The problem with using a non-upstream commit ID like this is that it likely
won't be the same once that commit is committed by Linus.

> I just wanted to let you know it depends on that.

The patch being part of the series is probably sufficient, though a note of
the subject line of the previous patch would be useful.

> What is the proper way to handle this?

A summary of the changes being made is good:

	ptrace: Fix up the arguments arch_ptrace() in arch FRV

	Fix up the arguments to arch_ptrace() to take account of the fact that
	addr and data are now unsigned long rather than long as of a preceding
	patch in this series.

	Signed-off-by: ...

Note, however, that if the earlier patch breaks the compilation and then this
patch fixes it up, you should roll this patch into the earlier patch, and the
earlier patch is not complete without it.

Think what happens if patch 3/43 breaks an arch, and then patch 43/43, say,
mends that arch, and then bisection lands on patch 3 during its progress.  You
may end up having to 'git bisect skip' all the patches between 3 and 43 one at
a time.

David
--
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/