linux-kernel - Re: Subject: [PATCH 00/91] pending uml patches

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, 19 Aug 2011 05:31:20 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Richard Weinberger <richard@....at>
Cc:	Al Viro <viro@....linux.org.uk>,
	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: Subject: [PATCH 00/91] pending uml patches

On Thu, Aug 18, 2011 at 08:19:46PM +0100, Al Viro wrote:
> On Thu, Aug 18, 2011 at 09:12:47PM +0200, Richard Weinberger wrote:
> > Have you touched your patches since yesterday?
> > I've already pulled and uploaded them to my shiny new git repo at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/rw/linux-um.git unstable
> 
> Reordered and added missing S-o-b on a couple, split one commit.

Umm...  One comment after looking at your tree: you probably want to rebase
for-3.2 on top of fixes (and presumably feed it to sfr for inclusion into
linux-next).

And for pity sake, do *not* merge from Linus every day; that's one sure
way to get yourself flamed into crisp.  Just trying to figure out
what's in your tree is a _hard_ exercise.  git cherry between Linus'
tree and e.g. #fixes in yours gives a long list of commits, most of them
_probably_ duplicates of the stuff in mainline.  What are bnx2 patches
doing in there, for example?

I've tried to figure out what's going on in there; AFAICS, your #fixes
is mainline plus
Al Viro (6):
      um: fix oopsable race in line_close()
      um: winch_interrupt() can happen inside of free_winch()
      um: fix free_winch() mess
      um: PTRACE_[GS]ETFPXREGS had been wired on the wrong subarch
      um: fix strrchr problems
      um: clean arch_ptrace() up a bit

Ingo van Lil (1):
      um: Save FPU registers between task switches

Jonathan Neusch<C3><A4>fer (3):
      UserModeLinux-HOWTO.txt: fix a typo
      um: drivers/xterm.c: fix a file descriptor leak
      UserModeLinux-HOWTO.txt: remove ^H characters

Thadeu Lima de Souza Cascardo (1):
      um: disable CMPXCHG_DOUBLE as it breaks UML build

	I've cherry-picked those on top of the same branchpoint; see
#cleaned-fixes in um-headers.git.  AFAICS, that's the same contents as
your #fixes, with clean history.  Diff against your #fixes consists of
-       .irq_set_type = pmic_irq_type, <<<<<<< HEAD
-       .irq_bus_lock           = pmic_irq_buslock,
+       .irq_set_type           = pmic_irq_type,
+       .irq_bus_lock           = pmic_bus_lock,
in drivers/platform/x86/intel_pmic_gpio.c, which is an obvious mismerge
(AFAICS, on May 29).

IME the sane policy is to keep for-linus, pulling into it when Linus
pulls from you.  At that point it's a fast-forward and all previous
history is not cluttering the things up anymore.  for-next I rebase and
reorder at will, TBH, but generally I start it at the current tip of
for-linus.

Beyond what you've got in #for-3.2 I have a couple of commits, but that
can wait until the history is sorted out.  As it is, I 100% guarantee
that pull request on your #fixes as it is will result in pyrotechnical
effects from hell (OK, from Linus, actually, but in this case there won't
be any real difference).

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