Skip to content
This repository has been archived by the owner on Sep 24, 2020. It is now read-only.

Rebase 4.14.48 patches onto 4.14.49 #197

Merged
merged 9 commits into from
Jun 12, 2018
Merged

Rebase 4.14.48 patches onto 4.14.49 #197

merged 9 commits into from
Jun 12, 2018

Conversation

dm0-
Copy link

@dm0- dm0- commented Jun 11, 2018

No description provided.

Vito Caputo and others added 9 commits June 11, 2018 16:54
This enables relocating source and build trees to different roots,
provided they stay reachable relative to one another.  Useful for
builds done within a sandbox where the eventual root is prefixed
by some undesirable path component.
blkdev_issue_zeroout() will use this in !BLKDEV_ZERO_NOFALLBACK case.

Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Ilya Dryomov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
sd_config_write_same() ignores ->max_ws_blocks == 0 and resets it to
permit trying WRITE SAME on older SCSI devices, unless ->no_write_same
is set.  Because REQ_OP_WRITE_ZEROES is implemented in terms of WRITE
SAME, blkdev_issue_zeroout() may fail with -EREMOTEIO:

  $ fallocate -zn -l 1k /dev/sdg
  fallocate: fallocate failed: Remote I/O error
  $ fallocate -zn -l 1k /dev/sdg  # OK
  $ fallocate -zn -l 1k /dev/sdg  # OK

The following calls succeed because sd_done() sets ->no_write_same in
response to a sense that would become BLK_STS_TARGET/-EREMOTEIO, causing
__blkdev_issue_zeroout() to fall back to generating ZERO_PAGE bios.

This means blkdev_issue_zeroout() must cope with WRITE ZEROES failing
and fall back to manually zeroing, unless BLKDEV_ZERO_NOFALLBACK is
specified.  For BLKDEV_ZERO_NOFALLBACK case, return -EOPNOTSUPP if
sd_done() has just set ->no_write_same thus indicating lack of offload
support.

Fixes: c20cfc2 ("block: stop using blkdev_issue_write_same for zeroing")
Cc: Hannes Reinecke <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Ilya Dryomov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
This reverts commit 70f3461.

This causes failures to set mtu > 1500 on some aws instances.
Recently people reported the NIC stops working after
"ifdown eth0; ifup eth0". It turns out in this case the TX queues are not
enabled, after the refactoring of the common detach logic: when the NIC
has sub-channels, usually we enable all the TX queues after all
sub-channels are set up: see rndis_set_subchannel() ->
netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where
the number of channels doesn't change, we also must make sure the TX queues
are enabled. The patch fixes the regression.

Fixes: 7b2ee50 ("hv_netvsc: common detach logic")
Signed-off-by: Dexuan Cui <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Cc: K. Y. Srinivasan <[email protected]>
Cc: Haiyang Zhang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
@dm0- dm0- merged commit b4898b9 into coreos:v4.14.49-coreos Jun 12, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants