Linux 3.11

Linux 3.11

[Linus Torvalds]

As some people noticed, I got distracted ("Ooh, look, a squirrel..")
and never wrote an announcement for -rc7. My bad. But it wasn't
actually all that interesting a release apart from the date, and it
had a silly compile error in ohci-pci if you hadn't enabled
CONFIG_PM_RUNTIME, so we'll just forget -rc7 ever happened, ok?
Instead, go and get the real 3.11 release, which is out there, all
shiny and ready to be compiled and loved.

Since rc7 (ok, I lied, it happened) there's been just small fixes.
Most of them came in from the networking tree, but there's some all
over: some random filesystem fixes, a couple of sound fixes, a
/proc/timer_list fix, things like that. Nothing really stands out
(unless you happened to use the new soft-dirty code, that had a buglet
that could really hurt), but let's hope we don't have some silly
configuration that doesn't even compile this time around.

Shortlog appended.

             Linus

---

Alan Stern (1):
      USB: OHCI: fix build error related to ohci_suspend/resume

Andrew Vagin (2):
      tcp: initialize rcv_tstamp for restored sockets
      tcp: don't apply tsoffset if rcv_tsecr is zero

Andrey Vagin (1):
      memcg: check that kmem_cache has memcg_params before accessing it

Andy Lutomirski (2):
      net: Check the correct namespace when spoofing pid over SCM_RIGHTS
      Rename nsproxy.pid_ns to nsproxy.pid_ns_for_children

Ariel Elior (4):
      bnx2x: vf mark stats started
      bnx2x: Fix functionality of configuring vlan list
      bnx2x: Fix VF memory leak unload
      bnx2x: Fix VF stats sync

Barry Song (2):
      irqchip: sirf: move from legacy mode to linear irqdomain
      arm: prima2: drop nr_irqs in mach as we moved to linear irqdomain

Benjamin Herrenschmidt (1):
      powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without
hypervisor

Byungho An (1):
      net: stmmac: fixed the pbl setting with DT

Chris Clark (1):
      ipv4: sendto/hdrincl: don't use destination address found in header

Cyrill Gorcunov (1):
      mm: move_ptes -- Set soft dirty bit depending on pte type

Dan Carpenter (1):
      mISDN: return -EINVAL on error in dsp_control_req()

Daniel Borkmann (1):
      net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

Dave Kleikamp (1):
      jfs: fix readdir cookie incompatibility with NFSv4

David Jander (1):
      regmap: rbtree: Fix overlapping rbnodes.

David S. Miller (1):
      Revert "ipv6: Don't depend on per socket memory for neighbour
discovery messages"

Eliezer Tamir (1):
      net: add cpu_relax to busy poll loop

Eric Dumazet (1):
      net: revert 8728c544a9c ("net: dev_pick_tx() fix")

Erik Hugne (1):
      tipc: set sk_err correctly when connection fails

Eugene Surovegin (1):
      powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.

Felix Fietkau (1):
      mac80211: add a flag to indicate CCK support for HT clients

Goldwyn Rodrigues (1):
      fs/ocfs2/super.c: Use bigger nodestr to accomodate 32-bit node numbers

Guenter Roeck (1):
      dma/Kconfig: TI_EDMA needs to be boolean

Hannes Frederic Sowa (7):
      xfrm: make local error reporting more robust
      xfrm: introduce helper for safe determination of mtu
      ipv6: wire up skb->encapsulation
      ipv6: xfrm: dereference inner ipv6 header if encapsulated
      xfrm: choose protocol family by skb protocol
      xfrm: revert ipv4 mtu determination to dst_mtu
      ipv6: set skb->protocol on tcp, raw and ip6_append_data genereated skbs

Hans Verkuil (1):
      [SCSI] pm80xx: fix Adaptec 71605H hang

Helmut Schaa (1):
      ath9k_htc: Restore skb headroom when returning skb to mac80211

Hugh Dickins (1):
      cgroup: fix rmdir EBUSY regression in 3.11

Ian Campbell (1):
      MAINTAINERS: change my DT related maintainer address

Imre Deak (1):
      drm/i915: ivb: fix edp voltage swing reg val

Jakob Bornecrantz (1):
      drm/vmwgfx: Split GMR2_REMAP commands if they are to large

Johannes Berg (1):
      mac80211: add missing channel context release

Kevin Hilman (1):
      regmap: Add another missing header for !CONFIG_REGMAP stubs

Li Hongjun (1):
      ipv4 tunnels: fix an oops when using ipip/sit with IPsec

Libo Chen (1):
      net: xilinx: fix memleak

Linus Lüssing (1):
      bridge: separate querier and query timer into IGMP/IPv4 and MLD/IPv6 ones

Linus Torvalds (2):
      Revert "fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flink"
      Linux 3.11

Mag (1):
      Input: xpad - add signature for Razer Onza Classic Edition

Matteo Delfino (1):
      Input: elantech - fix packet check for v3 and v4 hardware

Michal Schmidt (3):
      jme: lower NAPI weight
      netxen: lower NAPI weight
      ps3_gelic: lower NAPI weight

Mike Frysinger (1):
      Omnikey Cardman 4000: pull in ioctl.h in user header

Mischa Jonker (1):
      Input: i8042 - disable the driver on ARC platforms

Nathan Zimmer (1):
      timer_list: correct the iterator for timer_list

Paul Mackerras (1):
      powerpc: Work around gcc miscompilation of __pa() on 64-bit

Phil Oester (1):
      tcp: tcp_make_synack() should use sock_wmalloc

Ping Cheng (1):
      Input: wacom - add support for 0x300 and 0x301

Pravin B Shelar (2):
      genl: Fix genl dumpit() locking.
      genl: Hold reference on correct module while netlink-dump.

Richard Cochran (1):
      net: fec: fix time stamping logic after napi conversion

Rob Gardner (1):
      net: usb: Add HP hs2434 device to ZLP exception table

Russ Anderson (1):
      drivers/base/memory.c: fix show_mem_removable() to handle missing sections

Sarveshwar Bandi (1):
      be2net: Check for POST state in suspend-resume sequence

Simon Wunderlich (1):
      mac80211: ibss: fix ignored channel parameter

Stanislaw Gruszka (1):
      iwl4965: fix rfkill set state regression

Steffen Klassert (1):
      xfrm: Fix potential null pointer dereference in xdst_queue_output

Sujith Manoharan (1):
      ath9k: Enable PLL fix only for AR9340/AR9330

Svenning Sørensen (1):
      IPC: bugfix for msgrcv with msgtyp < 0

Takashi Iwai (3):
      ALSA: hda - Add inverted digital mic fixup for Acer Aspire One
      ALSA: hda - Fix NULL dereference with CONFIG_SND_DYNAMIC_MINORS=n
      ALSA: opti9xx: Fix conflicting driver object name

Tejun Heo (1):
      workqueue: cond_resched() after processing each work item

Thomas Graf (1):
      ipv6: Don't depend on per socket memory for neighbour discovery messages

Trond Myklebust (1):
      SUNRPC: Fix memory corruption issue on 32-bit highmem systems

Waiman Long (2):
      Add new lockref infrastructure reference implementation
      vfs: make the dentry cache use the lockref infrastructure

Yinghai Lu (1):
      x86/mm: Fix boot crash with DEBUG_PAGE_ALLOC=y and more than 512G RAM

Yuval Mintz (1):
      bnx2x: Fix move FP memory deallocations

Re: Linux 3.11

[Nicholas A. Bellinger]

On Mon, 2013-09-02 at 14:10 -0700, Linus Torvalds wrote:
> As some people noticed, I got distracted ("Ooh, look, a squirrel..")
> and never wrote an announcement for -rc7. My bad. But it wasn't
> actually all that interesting a release apart from the date, and it
> had a silly compile error in ohci-pci if you hadn't enabled
> CONFIG_PM_RUNTIME, so we'll just forget -rc7 ever happened, ok?
> Instead, go and get the real 3.11 release, which is out there, all
> shiny and ready to be compiled and loved.
> 
> Since rc7 (ok, I lied, it happened) there's been just small fixes.
> Most of them came in from the networking tree, but there's some all
> over: some random filesystem fixes, a couple of sound fixes, a
> /proc/timer_list fix, things like that. Nothing really stands out
> (unless you happened to use the new soft-dirty code, that had a buglet
> that could really hurt), but let's hope we don't have some silly
> configuration that doesn't even compile this time around.
> 
> Shortlog appended.
> 

Hi Linus,

Unfortunately, this doesn't include the remaining target fixes for
v3.11:

Re: [GIT PULL -v2] target fixes for v3.11
http://marc.info/?l=linux-kernel&m=137799048226191&w=2

Is there a reason why these did not get PULLed..?

Thanks,

--nab

Re: Linux 3.11

[Linus Torvalds]

On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
<nab@linux-iscsi.org> wrote:
>
> Unfortunately, this doesn't include the remaining target fixes for
> v3.11:
>
> Re: [GIT PULL -v2] target fixes for v3.11
> http://marc.info/?l=linux-kernel&m=137799048226191&w=2
>
> Is there a reason why these did not get PULLed..?

Very simple: I have no such email in my mailbox. I see the "target
updates for v3.11-rc1" email (and I pulled that), and there is nothing
since.

I don't even have that mail in my lkml archives, much less as a private email.

I see neither youe "-v2 PULL request" nor the "One more late v3.11
specific regression" one. In fact, I see no emails from you at all
from Aug 31.

It may be that gmail hates you for some reason...

[ time passes ]

Yup. It's in my spam-box, with gmail helpfully telling me:

   Why is this message in Spam? We've found that lots of messages from
linux-iscsi.org are spam.  Learn more

so something is rotten in the state of linux-iscsi.org.

Recent messages from you were similarly tagged:

 "[GIT PULL -v2] target fixes for 3.11"
 "Re: LIO FC Target"
 "Re: [GIT PULL] target fixes for v3.11-rc7"

there might have been more. You might want to try to figure out why
gmail thinks that linux-iscsi.org is spammy.

                Linus


                Linus

Re: Linux 3.11

[Guenter Roeck]

On 09/02/2013 03:50 PM, Linus Torvalds wrote:
> On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
>>
>> Unfortunately, this doesn't include the remaining target fixes for
>> v3.11:
>>
>> Re: [GIT PULL -v2] target fixes for v3.11
>> http://marc.info/?l=linux-kernel&m=137799048226191&w=2
>>
>> Is there a reason why these did not get PULLed..?
>
> Very simple: I have no such email in my mailbox. I see the "target
> updates for v3.11-rc1" email (and I pulled that), and there is nothing
> since.
>
> I don't even have that mail in my lkml archives, much less as a private email.
>
> I see neither youe "-v2 PULL request" nor the "One more late v3.11
> specific regression" one. In fact, I see no emails from you at all
> from Aug 31.
>
> It may be that gmail hates you for some reason...
>
> [ time passes ]
>
> Yup. It's in my spam-box, with gmail helpfully telling me:
>
>     Why is this message in Spam? We've found that lots of messages from
> linux-iscsi.org are spam.  Learn more
>
> so something is rotten in the state of linux-iscsi.org.
>
> Recent messages from you were similarly tagged:
>
>   "[GIT PULL -v2] target fixes for 3.11"
>   "Re: LIO FC Target"
>   "Re: [GIT PULL] target fixes for v3.11-rc7"
>
> there might have been more. You might want to try to figure out why
> gmail thinks that linux-iscsi.org is spammy.
>

I don't think it has anything to do with linux-iscsi.org.
Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
sent through it can not be logged and examined by a certain US government agency.

I had the same experience; Google blocks all e-mail from my private provider
(located in Singapore). When asked by the provider, they claimed to know
nothing about it. No, my provider doesn't forward more spam than other providers,
and definitely less than, say, Yahoo.

I can only recommend for everyone to send pull requests through a gmail account.
If you set it up correctly, you can keep using your non-gmail source address
but still send it through a Google server. Just don't use it for anything else
unless you don't mind Big Brother listening in.

Guenter

RE: linux 3.11

[Juan Barry Manuel Canham]

I noticed that linux-iscsi.org isn't doing much to protect itself from being 
used as a spam source. If you setup the following you should be less likely to 
be marked as spam:

* SPF record (setup both spf and a txt spf record for compatibility) 
* DMARC record to enforce SPF and allow servers to contact you when linux-
iscsi.org is used as a spam source
* DKIM - more work and probably not needed, but I suspect having valid dkim 
signatures will help with some mail servers spam rankings 

Apologies as this isn't really Linux kernel related stuff but it might help 
other developers avoid being spammed by gmail too.

Re: Linux 3.11

[Nicholas A. Bellinger]

On Mon, 2013-09-02 at 15:50 -0700, Linus Torvalds wrote:
> On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
> >
> > Unfortunately, this doesn't include the remaining target fixes for
> > v3.11:
> >
> > Re: [GIT PULL -v2] target fixes for v3.11
> > http://marc.info/?l=linux-kernel&m=137799048226191&w=2
> >
> > Is there a reason why these did not get PULLed..?
> 
> Very simple: I have no such email in my mailbox. I see the "target
> updates for v3.11-rc1" email (and I pulled that), and there is nothing
> since.
> 
> I don't even have that mail in my lkml archives, much less as a private email.
> 
> I see neither youe "-v2 PULL request" nor the "One more late v3.11
> specific regression" one. In fact, I see no emails from you at all
> from Aug 31.
> 
> It may be that gmail hates you for some reason...
> 
> [ time passes ]
> 
> Yup. It's in my spam-box, with gmail helpfully telling me:
> 
>    Why is this message in Spam? We've found that lots of messages from
> linux-iscsi.org are spam.  Learn more
> 
> so something is rotten in the state of linux-iscsi.org.
> 
> Recent messages from you were similarly tagged:
> 
>  "[GIT PULL -v2] target fixes for 3.11"
>  "Re: LIO FC Target"
>  "Re: [GIT PULL] target fixes for v3.11-rc7"
> 
> there might have been more. You might want to try to figure out why
> gmail thinks that linux-iscsi.org is spammy.

Mmmm, that is what I was afraid of, looking into that now..

So if you would, please go ahead and pull target-pending/master ASAP for
the fixes, and I'll send the parts that need to goto Greg-KH separately.

Thanks,

--nab

Re: Linux 3.11

[Theodore Ts'o]

On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
> I don't think it has anything to do with linux-iscsi.org.
> Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
> sent through it can not be logged and examined by a certain US government agency.

Hardly.  mail.linux-iscsi.org is hosted by Rackspace, which is most
certainly in the US.  There may be spammers using some of Rackspace
subnets, which is much more likely to have something to be the issue.

I had a similar issue with thunk.org, which is hosted by Linode.  In
my case, part of the problem was that I was that I moved my host to a
different Linode datacenter (from Dallas to Atlanta), and I forgot to
update my SPF record, so e-mails with an SMTP envelope address of
tytso@thunk.org were getting a soft-fail.  (And e-mails with an SMTP
return address of tytso@mit.edu but sent from imap.thunk.org were
always getting a soft-fail, which would tend to increase the
likelihood that if the e-mail tripped other hueristics, would cause it
to be considered spam.)

Fixing my SPF record, and enabling DKIM (with a DKIM key published for
thunk.org in DNS, and making sure that I always used an SMTP envelope
return address of tytso@thunk.org, even if the RFC 822 from address
stated tytso@mit.edu) fixed the spam false positive issues for me.

(Hint: installing and configuring OpenDKIM really isn't all that hard.
I did it in less than an hour.)

> I had the same experience; Google blocks all e-mail from my private provider
> (located in Singapore). When asked by the provider, they claimed to know
> nothing about it. No, my provider doesn't forward more spam than other providers,
> and definitely less than, say, Yahoo.

One of the things that might be happening is that your private
provider may be hosting mailing lists used by companies to send
marketing "newsletters".  Unfortunately, sometimes it's a pain to
subscribe from such newsletters, and some users will just simply hit
the "it's spam" button to make such newsletters go away.  For a small
provider, it's easier for a percentage of e-mails being emitted from a
mailer to be considered spam to exceed some magic threshold, thus
increasing the "spam score" for e-mails originating from that
provider.

I'll also note that Yahoo uses DKIM (heck, it invented DKIM) and using
DKIM is useful because if someone tries to fake spam using your
domain, if your e-mails are getting signed using DKIM, and the spam is
getting sent without being DKIM signed, many of the anti-spam
filtering services defintiely do take this into account.  Some may
even automatically decrease your spam score slightly just because you
are using DKIM, just because spammers tend not to do this, and using
DKIM to sign your e-mail headers makes it easier for spam filtering
systems to hold senders accountable for spam that they send.

	  	   	      	      - Ted

P.S.  Although I work for Google, I don't know anything about the
low-level details of how Google's anti-SPAM systems work.  However,
for almost a decade, I was a member of MIT Network Operations, and was
one of the postmasters for mit.edu, back when aol.com was in its prime
(and we had a larger number of SMTP deliveries per day than AOL did).
So I know a thing or two about e-mail.... and I'd be really surprised
if anyone, particular a major mail provider such as Google, Yahoo,
Hotmail, etc, was filtering e-mail just because it came from a non-US
mail server.

The reality is that e-mail is international, and it's only the admins
of smaller mail services (perhaps desperate to filter out vast
quantities of Russian or Chinese Spam, and figuring that they weren't
expecting any valid e-mails from those countries), that would do
something as silly has filtering based on geographic source locations.

Re: Linux 3.11

[Nicholas A. Bellinger]

Hi Ted,

On Mon, 2013-09-02 at 22:17 -0400, Theodore Ts'o wrote:
> On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
> > I don't think it has anything to do with linux-iscsi.org.
> > Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
> > sent through it can not be logged and examined by a certain US government agency.
> 
> Hardly.  mail.linux-iscsi.org is hosted by Rackspace, which is most
> certainly in the US.  There may be spammers using some of Rackspace
> subnets, which is much more likely to have something to be the issue.
> 
> I had a similar issue with thunk.org, which is hosted by Linode.  In
> my case, part of the problem was that I was that I moved my host to a
> different Linode datacenter (from Dallas to Atlanta), and I forgot to
> update my SPF record, so e-mails with an SMTP envelope address of
> tytso@thunk.org were getting a soft-fail.  (And e-mails with an SMTP
> return address of tytso@mit.edu but sent from imap.thunk.org were
> always getting a soft-fail, which would tend to increase the
> likelihood that if the e-mail tripped other hueristics, would cause it
> to be considered spam.)
> 
> Fixing my SPF record, and enabling DKIM (with a DKIM key published for
> thunk.org in DNS, and making sure that I always used an SMTP envelope
> return address of tytso@thunk.org, even if the RFC 822 from address
> stated tytso@mit.edu) fixed the spam false positive issues for me.
> 
> (Hint: installing and configuring OpenDKIM really isn't all that hard.
> I did it in less than an hour.)

<nod>, thanks for the additional information.

Enabling DKIM now, and just waiting for the TXT records to update to
verify.

--nab

Re: Linux 3.11

[Geert Uytterhoeven]

On Tue, Sep 3, 2013 at 12:50 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>> Is there a reason why these did not get PULLed..?
>
> Very simple: I have no such email in my mailbox. I see the "target
> updates for v3.11-rc1" email (and I pulled that), and there is nothing
> since.
>
> I don't even have that mail in my lkml archives, much less as a private email.
>
> I see neither youe "-v2 PULL request" nor the "One more late v3.11
> specific regression" one. In fact, I see no emails from you at all
> from Aug 31.
>
> It may be that gmail hates you for some reason...
>
> [ time passes ]
>
> Yup. It's in my spam-box, with gmail helpfully telling me:
>
>    Why is this message in Spam? We've found that lots of messages from
> linux-iscsi.org are spam.  Learn more
>
> so something is rotten in the state of linux-iscsi.org.

Funny, I did receive it without spam-label.

I do search for "label:linux-kernel in:spam" once in a while, to unspam some.
Perhaps I taught gmail Nicholas' emails are not spam for me ;-)

Note that a long time ago, I added special gmail filters to not mark emails from
some kernel-hacking Google employees as spam. Just marking them as not spam
over and over didn't help, as they were using non-google SMTP servers for
their outgoing email.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Linux 3.11

[Theodore Ts'o]

On Mon, Sep 02, 2013 at 07:56:13PM -0700, Nicholas A. Bellinger wrote:
> 
> Enabling DKIM now, and just waiting for the TXT records to update to
> verify.

The best way to verify is to send your test-email e-mail to GMail, and
then select "Show Original" from the per-message drop-down menu when
you view the message using GMail.  Then look for the
"Authentication-Results" mail header:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of tytso@thunk.org designates 2600:3c02::f03c:91ff:fe96:be03 as permitted sender) smtp.mail=tytso@thunk.org;
       dkim=pass header.i=@thunk.org

This will confirm whether or not you got all of the details right.
And note that Google is IPv6-enabled, which means that if you are
using SPF, and your mail server on Rackspace also has IPv6 enabled
(which is likely), do make sure your SPF records includes both its
IPV4 and IPV6 addresses; or else you might be getting an SPF soft- or
hard- fail that could end up marking your mail as possibly being spam,
even if other mail servers which are not IPv6 enabled think it's fine.

Good luck,

						- Ted

Re: Linux 3.11

[Nicholas A. Bellinger]

Hi again Linus,

On Mon, 2013-09-02 at 17:50 -0700, Nicholas A. Bellinger wrote:
> On Mon, 2013-09-02 at 15:50 -0700, Linus Torvalds wrote:
> > On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
> > <nab@linux-iscsi.org> wrote:
> > >
> > > Unfortunately, this doesn't include the remaining target fixes for
> > > v3.11:
> > >
> > > Re: [GIT PULL -v2] target fixes for v3.11
> > > http://marc.info/?l=linux-kernel&m=137799048226191&w=2
> > >
> > > Is there a reason why these did not get PULLed..?
> > 
> > Very simple: I have no such email in my mailbox. I see the "target
> > updates for v3.11-rc1" email (and I pulled that), and there is nothing
> > since.
> > 
> > I don't even have that mail in my lkml archives, much less as a private email.
> > 
> > I see neither youe "-v2 PULL request" nor the "One more late v3.11
> > specific regression" one. In fact, I see no emails from you at all
> > from Aug 31.
> > 
> > It may be that gmail hates you for some reason...
> > 
> > [ time passes ]
> > 
> > Yup. It's in my spam-box, with gmail helpfully telling me:
> > 
> >    Why is this message in Spam? We've found that lots of messages from
> > linux-iscsi.org are spam.  Learn more
> > 
> > so something is rotten in the state of linux-iscsi.org.
> > 
> > Recent messages from you were similarly tagged:
> > 
> >  "[GIT PULL -v2] target fixes for 3.11"
> >  "Re: LIO FC Target"
> >  "Re: [GIT PULL] target fixes for v3.11-rc7"
> > 
> > there might have been more. You might want to try to figure out why
> > gmail thinks that linux-iscsi.org is spammy.
> 
> Mmmm, that is what I was afraid of, looking into that now..
> 
> So if you would, please go ahead and pull target-pending/master ASAP for
> the fixes, and I'll send the parts that need to goto Greg-KH separately.
> 

Ok, so another PULL request was sent out last night for the missing
target fixes below, after putting DKIM + SPF authentication in place for
linux-iscsi.org:

[GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
http://marc.info/?l=linux-kernel&m=137818849925625&w=2

Watching the recent git activity, I can't tell if you've (not) reached
this point in the PULL queue yet, or if this email also landed in your
spam folder..?

Care to give me a hint if your receiving these PULL emails now, or if I
need to continue looking at why gmail is unhappy..?

Thank you,

--nab 

Re: Linux 3.11

[Linus Torvalds]

On Tue, Sep 3, 2013 at 2:46 PM, Nicholas A. Bellinger
<nab@linux-iscsi.org> wrote:
>
> Ok, so another PULL request was sent out last night for the missing
> target fixes below, after putting DKIM + SPF authentication in place for
> linux-iscsi.org:
>
> [GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
> http://marc.info/?l=linux-kernel&m=137818849925625&w=2
>
> Watching the recent git activity, I can't tell if you've (not) reached
> this point in the PULL queue yet, or if this email also landed in your
> spam folder..?
>
> Care to give me a hint if your receiving these PULL emails now, or if I
> need to continue looking at why gmail is unhappy..?

That message came through, and has the line

  Received-SPF: pass (google.com: domain of nab@linux-iscsi.org
designates 67.23.28.174 as permitted sender) client-ip=67.23.28.174;

which may or may not have been the thing that made a difference.

I'll get to the pull request itself later..

              Linus

Re: Linux 3.11

[Nicholas A. Bellinger]

On Tue, 2013-09-03 at 15:44 -0700, Linus Torvalds wrote:
> On Tue, Sep 3, 2013 at 2:46 PM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
> >
> > Ok, so another PULL request was sent out last night for the missing
> > target fixes below, after putting DKIM + SPF authentication in place for
> > linux-iscsi.org:
> >
> > [GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
> > http://marc.info/?l=linux-kernel&m=137818849925625&w=2
> >
> > Watching the recent git activity, I can't tell if you've (not) reached
> > this point in the PULL queue yet, or if this email also landed in your
> > spam folder..?
> >
> > Care to give me a hint if your receiving these PULL emails now, or if I
> > need to continue looking at why gmail is unhappy..?
> 
> That message came through, and has the line
> 
>   Received-SPF: pass (google.com: domain of nab@linux-iscsi.org
> designates 67.23.28.174 as permitted sender) client-ip=67.23.28.174;
> 
> which may or may not have been the thing that made a difference.
> 

Excellent, thanks for confirming it made it through this time.

> I'll get to the pull request itself later..
> 

<nod>, now back to the real v3.12-rc1 items.

Thanks again,

--nab

Re: Linux 3.11

[Willy Tarreau]

On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
> I can only recommend for everyone to send pull requests through a gmail 
> account.

The problem I'm seeing with this method to combat abusive filtering from
e-mail providers is that we'll quickly end up needing to have one account
per provider depending on whom we want to send mail. It's not e-mail anymore
if you need to transfer them from inside the recipient's network, really...

Willy