This moves the quirk itself to pci_64.c as to get built on all ppc64
platforms (the only ones with a pci_dn), factors the two implementations
of get_pdn() into a single pci_get_dn() and use the quirk to do 32-bit
MSIs on IODA based powernv platforms.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
In commit 9353374 "Context switch the new EBB SPRs" we added support for
context switching some new EBB SPRs. However despite four of us signing
off on that patch we missed some. To be fair these are not actually new
SPRs, but they are now potentially user accessible so need to be context
switched.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We use two flags, one to indicate an invalidation is needed after
creating a new entry and one to indicate an invalidation is needed
after removing an entry. However we were testing the wrong flag
in the remove case.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The message is only meant to be displayed if resource 0 is empty,
but was displayed if any is.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The TLB has 512 congruence classes (2048 entries 4 way set associative)
while P7 had 128
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for vt8500 as well.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Tony Prisk <linux@prisktech.co.nz>
Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for virt as well.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for vexpress as well.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for sirf as well.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Barry Song <Baohua.Song@csr.com>
Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for spear as well.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for nomadik as well.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Fixes a race on driver init with registering algorithms where the
driver status flag wasn't being set before self testing started.
Added the cra_alignmask field for CBC and ECB modes.
Fixed a bug in GCM where AES block size was being used instead of
authsize.
Removed use of blkcipher_walk routines for scatterlist processing.
Corner cases in the code prevent us from processing an entire
scatterlist at a time and walking the buffers in block sized chunks
turns out to be unecessary anyway.
Fixed off-by-one error in saving off extra data in the sha code.
Fixed accounting error for number of bytes processed in the sha code.
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The CSPI controller has only one clock, but the driver spi-imx.c needs
clock "per" to calculate bitrate divisor.
Signed-off-by: Jonas Andersson <jonas@microbit.se>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The motivation for this is to allow the driver to be
used with the r8a7790 SoC.
I believe that rather than adding another SoC to the list of allowed SoCs
it is better to simply remove the dependency of the driver on shmobile all
together.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Tejun Heo <tj@kernel.org>
Refactor all TX HW workarounds into a separate routine called
be_xmit_workarounds().
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In function be_get_nic_desc(), it will go through the descriptor array
returned from f/w. By comparing the desc_type field, it determines whether
there is a nic descriptor in the array or not. In the case of no nic
descriptor, this function should return NULL.
The code may return an invalide descriptor, when there is no nic descriptor
in the array and the desc_count is less than MAX_RESOURCE_DESC. In this case,
even there is no nic descriptor, it will still return the lase descriptor
since the i doesn't equal to MAX_RESOURCE_DESC.
This patch fix this issue by returning the descriptor when find it and return
NULL for other cases.
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Reviewed-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Reviewed-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Acked-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
During a config change, propagate_exception() needs to traverse the
subtree to update config on the subtree. Because such config updates
need to allocate memory, it couldn't directly use
cgroup_for_each_descendant_pre() which required the whole iteration to
be contained in a single RCU read critical section. To work around
the limitation, propagate_exception() built a linked list of
descendant cgroups while read-locking RCU and then walked the list
afterwards, which is safe as the whole iteration is protected by
devcgroup_mutex. This works but is cumbersome.
With the recent updates, cgroup iterators now allow dropping RCU read
lock while iteration is in progress making this workaround no longer
necessary. This patch replaces dev_cgroup->propagate_pending list and
get_online_devcg() with direct cgroup_for_each_descendant_pre() walk.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Aristeu Rozanski <aris@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
This patch converts cgroup_for_each_child(),
cgroup_next_descendant_pre/post() and thus
cgroup_for_each_descendant_pre/post() to use cgroup_next_sibling()
instead of manually dereferencing ->sibling.next.
The only reason the iterators couldn't allow dropping RCU read lock
while iteration is in progress was because they couldn't determine the
next sibling safely once RCU read lock is dropped. Using
cgroup_next_sibling() removes that problem and enables all iterators
to allow dropping RCU read lock in the middle. Comments are updated
accordingly.
This makes the iterators easier to use and will simplify controllers.
Note that @cgroup argument is renamed to @cgrp in
cgroup_for_each_child() because it conflicts with "struct cgroup" used
in the new macro body.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Currently, there's no easy way to find out the next sibling cgroup
unless it's known that the current cgroup is accessed from the
parent's children list in a single RCU critical section. This in turn
forces all iterators to require whole iteration to be enclosed in a
single RCU critical section, which sometimes is too restrictive. This
patch implements cgroup_next_sibling() which can reliably determine
the next sibling regardless of the state of the current cgroup as long
as it's accessible.
It currently is impossible to determine the next sibling after
dropping RCU read lock because the cgroup being iterated could be
removed anytime and if RCU read lock is dropped, nothing guarantess
its ->sibling.next pointer is accessible. A removed cgroup would
continue to point to its next sibling for RCU accesses but stop
receiving updates from the sibling. IOW, the next sibling could be
removed and then complete its grace period while RCU read lock is
dropped, making it unsafe to dereference ->sibling.next after dropping
and re-acquiring RCU read lock.
This can be solved by adding a way to traverse to the next sibling
without dereferencing ->sibling.next. This patch adds a monotonically
increasing cgroup serial number, cgroup->serial_nr, which guarantees
that all cgroup->children lists are kept in increasing serial_nr
order. A new function, cgroup_next_sibling(), is implemented, which,
if CGRP_REMOVED is not set on the current cgroup, follows
->sibling.next; otherwise, traverses the parent's ->children list
until it sees a sibling with higher ->serial_nr.
This allows the function to always return the next sibling regardless
of the state of the current cgroup without adding overhead in the fast
path.
Further patches will update the iterators to use cgroup_next_sibling()
so that they allow dropping RCU read lock and blocking while iteration
is in progress which in turn will be used to simplify controllers.
v2: Typo fix as per Serge.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
cgroup_is_removed() no longer has external users and it shouldn't grow
any - controllers should deal with cgroup_subsys_state on/offline
state instead of cgroup removal state. Make it static.
While at it, make it return bool.
Signed-off-by: Tejun Heo <tj@kernel.org>
Explain the mechanism and API of the recently merged
rps flow limit patch.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When vlan device is configured on top of the brige, it does
not support any offload capabilities because the bridge
device does not initiliaze vlan_fatures. Set vlan_fatures to
be equivalent to hw_fatures.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yuval Mintz says:
====================
This series contain several small enhancements - chief among those are
the implementation of ethtool's private flags callback to share information
about the storage offload capabilities of its network interfaces,
and the prevention of a link flap when booting from storage area networks.
Changes from V1:
- Patch 1, removed trailing whitespaces from private flag strings.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Merging to receive 7805d000db ("cgroup: fix a subtle bug in descendant
pre-order walk") so that further iterator updates can build upon it.
Signed-off-by: Tejun Heo <tj@kernel.org>
When cgroup_next_descendant_pre() initiates a walk, it checks whether
the subtree root doesn't have any children and if not returns NULL.
Later code assumes that the subtree isn't empty. This is broken
because the subtree may become empty inbetween, which can lead to the
traversal escaping the subtree by walking to the sibling of the
subtree root.
There's no reason to have the early exit path. Remove it along with
the later assumption that the subtree isn't empty. This simplifies
the code a bit and fixes the subtle bug.
While at it, fix the comment of cgroup_for_each_descendant_pre() which
was incorrectly referring to ->css_offline() instead of
->css_online().
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Cc: stable@vger.kernel.org
In Multi-function mode, all functions should be able to utilize said function;
There's no reason why only the link owner should be able to do so.
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
During PCIe advanced error recovery, the secondary bus reset will cause FW
to reset; This will cause the shared memory between it and the driver to be
invalidated.
During the driver's recovery flow, the driver should not make any assumption
on the validity of that memory and instead re-initialize it.
This also removes a redundant re-initialization of a previously
initialized mutex.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As part of the previous unload flow, probed devices will reset the chip
in order to clean the remains of the UNDI driver.
As a result, it's possible for the FW to toggle the link.
This toggling can prove fatal, as long periods without link can cause the
filesystem mount to fail as the storage protocol timeouts. This has been
observed against particular switches with long link re-establishment time.
This patch informs FW during the reset period that the link should not
be toggled - the FW will keep it alive until some interface will load and claim
the link as its own.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Utilize ethtool's callback `get_priv_flags' - shed more light on the
feasibility of devices as storage interfaces.
CC: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Wei Liu says:
====================
This series adds a new feature called split event channels.
In the original implementation, only one event channel is setup between
frontend and backend. This is not ideal as TX notification interferes with RX
notification. Using dedicated event channels for TX and RX solves this issue.
Changes since V2:
* feature_split_event_channels -> separate_tx_rx_irq
* make separate_tx_rx_irq bool
* document this feature in header file
* don't report fatal if writing feature to xenstore fails
* frontend will fall back to single event channel if new feature setup fails
Changes since V1:
* change subject lines of commits to be more specific
* add parameter feature_split_event_channels for xen-netback
* remove two dev_info
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch synchronises documentation for feature-split-event-channels from
Xen canonical header file.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds a new feature called feature-split-event-channels for
netfront, enabling it to handle TX and RX events separately.
If netback does not support this feature, it falls back to use single event
channel.
If netfront fails to setup split event channels, it will try falling back to
single event channel.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Netback and netfront only use one event channel to do TX / RX notification,
which may cause unnecessary wake-up of processing routines. This patch adds a
new feature called feature-split-event-channels to netback, enabling it to
handle TX and RX events separately.
Netback will use tx_irq to notify guest for TX completion, rx_irq for RX
notification.
If frontend doesn't support this feature, tx_irq equals to rx_irq.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 3853b5841c ("xps: Improvements in TX queue selection")
introduced ooo_okay flag, but the condition to set it is slightly wrong.
In our traces, we have seen ACK packets being received out of order,
and RST packets sent in response.
We should test if we have any packets still in host queue.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
- An OMAP fix that makes ethernet work again.
- Fix for build problem when building the MCP23S08 driver
as module.
- IRQ conflicts in the Langwell driver.
- Fix IRQ coherency issues in the MXS driver.
- Return correct errorcode on errorpath when removing
GPIO chips.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJRnofTAAoJEEEQszewGV1zcwEQAJcPAYa/+h4vYAYtQ95dK2Wo
l155ifP7UmpHmEVkTiDsNG7ugGeoaPtfAh3y5ovSqSikr4NrtCVAZ+daivZnJzDu
IzrutXAJiJn+5hE7k6loq979o1xbIJVQtPORJDb7KoeoS0tmPvBt2DDBvyFYZXR+
+hhsG1PNDq4cBXsxNPPAUbYSsXjUeuNib1kM/wdgBJ+h0p8BT24Wc7C61y/ndl+R
fAXfZNpJnBTF451z683FwuTziC5P3S30nf3uU0n0n4qwn3/TzlNMgdp7SO2zbDqh
bsp/mVQ0PCunOWylthRTf5mW0rRy4RfZZsEcSk2YV750nJ/MT1VTloCPppHPga2i
R117Ype9cQyxtKpPRcNaaTJXZsCy7S0/dTMVAWXCIV2tjXASQ11a1HAKLTi3vzqL
ygl/vsb2W1mLL50B+KDqFtSgVBR9i4eyTx4KRE6Sg96XxjUzhIqAKUUC0ZJHgO4F
sJPqHxbWvlhge8p0Z+SEbWuznQrt8RZfQP8197B3/bvGQ6i2uPcBYQdyWxyD3bFR
IvUuy0kN/GtlGHx4+REbLinLkX2ngXmSoZePxR+eDSccqy0XSe+dscdg1gGir2g4
6bG8zidXvCIkuaVlkPV1DJY5kzZrHnGGqgtNBrb7nRY7MA6jZ114sBIvR7dAkR7g
xQyHh1q9vkRzttOInwB0
=dxQl
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-v3.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
- An OMAP fix that makes ethernet work again.
- Fix for build problem when building the MCP23S08 driver as module.
- IRQ conflicts in the Langwell driver.
- Fix IRQ coherency issues in the MXS driver.
- Return correct errorcode on errorpath when removing GPIO chips.
* tag 'gpio-fixes-v3.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: Don't override the error code in probe error handling
gpio: mxs: Use set and clear capabilities of the gpio controller
gpio-langwell: fix irq conflicts when DT is not used
gpio: mcp23s08: Fix build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m
gpio/omap: ensure gpio context is initialised
Daniel writes:
A few fixes, nothing shocking:
- More Haswell pci ids. Includes a pile of marketing spare ids (which
despite the spare moniker show up all over the place).
- Fix a regression in handling modeset failures, resulting in black
screens on 3 pipe setups when we've run out of pch plls (Chris).
- Fix up the setcrtc semantics to unconditionally enable the outputs.
Juding from git digging that has (kinda) always been the case and neatly
fixes a few long-standing (i.e. forever) bug reports (Imre).
- jiffies_timeout + 1 patches from Imre. They partially fix spurious
wait_event failures in the interrupt-driven dp aux/i2c code. The other
part is a core patch for the wait_event macros going in through -mm. A
few patches more than strictly required since Imre is pushing for a
general solution in 3.11.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: avoid premature DP AUX timeouts
drm/i915: avoid premature timeouts in __wait_seqno()
drm/i915: use msecs_to_jiffies_timeout instead of open coding the same
drm/i915: add msecs_to_jiffies_timeout to guarantee minimum duration
drm/i915: force full modeset if the connector is in DPMS OFF mode
drm/i915: Propagate errors back from fb set-base
drm/i915: Adding more reserved PCI IDs for Haswell.
Inki writes:
This pull request includes drm_send_vblank_event() helper
relevant patch I missed and code cleanups. And also it fixes
a pended page flip issue.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: replace request_threaded_irq with devm function
drm/exynos: remove unnecessary devm_kfree
drm/exynos: fix build warnings from ipp fimc
drm/exynos: cleanup device pointer usages
drm/exynos: wait for the completion of pending page flip
drm/exynos: use drm_send_vblank_event() helper
drm/exynos: page flip fixes
drm/exynos: exynos_hdmi: Pass correct pointer to free_irq()
drm/exynos: exynos_drm_ipp: Fix incorrect usage of IS_ERR_OR_NULL
drm/exynos: exynos_drm_fbdev: Fix incorrect usage of IS_ERR_OR_NULL
Conflicts:
drivers/gpu/drm/exynos/exynos_hdmi.c
Allow to compile the driver all the time if AT91 enabled.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: Bo Shen <voice.shen@atmel.com>
so we can have multiple usb gadget instance
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: Bo Shen <voice.shen@atmel.com>
Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.
Cc: stable@vger.kernel.org [2.6.33+]
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Note: this changes the on-disk remote attribute format. I assert
that this is OK to do as CRCs are marked experimental and the first
kernel it is included in has not yet reached release yet. Further,
the userspace utilities are still evolving and so anyone using this
stuff right now is a developer or tester using volatile filesystems
for testing this feature. Hence changing the format right now to
save longer term pain is the right thing to do.
The fundamental change is to move from a header per extent in the
attribute to a header per filesytem block in the attribute. This
means there are more header blocks and the parsing of the attribute
data is slightly more complex, but it has the advantage that we
always know the size of the attribute on disk based on the length of
the data it contains.
This is where the header-per-extent method has problems. We don't
know the size of the attribute on disk without first knowing how
many extents are used to hold it. And we can't tell from a
mapping lookup, either, because remote attributes can be allocated
contiguously with other attribute blocks and so there is no obvious
way of determining the actual size of the atribute on disk short of
walking and mapping buffers.
The problem with this approach is that if we map a buffer
incorrectly (e.g. we make the last buffer for the attribute data too
long), we then get buffer cache lookup failure when we map it
correctly. i.e. we get a size mismatch on lookup. This is not
necessarily fatal, but it's a cache coherency problem that can lead
to returning the wrong data to userspace or writing the wrong data
to disk. And debug kernels will assert fail if this occurs.
I found lots of niggly little problems trying to fix this issue on a
4k block size filesystem, finally getting it to pass with lots of
fixes. The thing is, 1024 byte filesystems still failed, and it was
getting really complex handling all the corner cases that were
showing up. And there were clearly more that I hadn't found yet.
It is complex, fragile code, and if we don't fix it now, it will be
complex, fragile code forever more.
Hence the simple fix is to add a header to each filesystem block.
This gives us the same relationship between the attribute data
length and the number of blocks on disk as we have without CRCs -
it's a linear mapping and doesn't require us to guess anything. It
is simple to implement, too - the remote block count calculated at
lookup time can be used by the remote attribute set/get/remove code
without modification for both CRC and non-CRC filesystems. The world
becomes sane again.
Because the copy-in and copy-out now need to iterate over each
filesystem block, I moved them into helper functions so we separate
the block mapping and buffer manupulations from the attribute data
and CRC header manipulations. The code becomes much clearer as a
result, and it is a lot easier to understand and debug. It also
appears to be much more robust - once it worked on 4k block size
filesystems, it has worked without failure on 1k block size
filesystems, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
xfs_attr3_leaf_compact() uses a temporary buffer for compacting the
the entries in a leaf. It copies the the original buffer into the
temporary buffer, then zeros the original buffer completely. It then
copies the entries back into the original buffer. However, the
original buffer has not been correctly initialised, and so the
movement of the entries goes horribly wrong.
Make sure the zeroed destination buffer is fully initialised, and
once we've set up the destination incore header appropriately, write
is back to the buffer before starting to move entries around.
While debugging this, the _d/_s prefixes weren't sufficient to
remind me what buffer was what, so rename then all _src/_dst.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
xfs_attr3_leaf_unbalance() uses a temporary buffer for recombining
the entries in two leaves when the destination leaf requires
compaction. The temporary buffer ends up being copied back over the
original destination buffer, so the header in the temporary buffer
needs to contain all the information that is in the destination
buffer.
To make sure the temporary buffer is fully initialised, once we've
set up the temporary incore header appropriately, write is back to
the temporary buffer before starting to move entries around.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Commit 79d852bf "NFS: Retry SETCLIENTID with AUTH_SYS instead of
AUTH_NONE" did not take into account commit 23631227 "NFSv4: Fix the
fallback to AUTH_NULL if krb5i is not available".
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
If we don't map the buffers correctly (same as for get/set
operations) then the incore buffer lookup will fail. If a block
number matches but a length is wrong, then debug kernels will ASSERT
fail in _xfs_buf_find() due to the length mismatch. Ensure that we
map the buffers correctly by basing the length of the buffer on the
attribute data length rather than the remote block count.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
When an attribute data does not fill then entire remote block, we
zero the remaining part of the buffer. This, however, needs to take
into account that the buffer has a header, and so the offset where
zeroing starts and the length of zeroing need to take this into
account. Otherwise we end up with zeros over the end of the
attribute value when CRCs are enabled.
While there, make sure we only ask to map an extent that covers the
remaining range of the attribute, rather than asking every time for
the full length of remote data. If the remote attribute blocks are
contiguous with other parts of the attribute tree, it will map those
blocks as well and we can potentially zero them incorrectly. We can
also get buffer size mistmatches when trying to read or remove the
remote attribute, and this can lead to not finding the correct
buffer when looking it up in cache.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Reading a maximally size remote attribute fails when CRCs are
enabled with this verification error:
XFS (vdb): remote attribute header does not match required off/len/owner)
There are two reasons for this, the first being that the
length of the buffer being read is determined from the
args->rmtblkcnt which doesn't take into account CRC headers. Hence
the mapped length ends up being too short and so we need to
calculate it directly from the value length.
The second is that the byte count of valid data within a buffer is
capped by the length of the data and so doesn't take into account
that the buffer might be longer due to headers. Hence we need to
calculate the data space in the buffer first before calculating the
actual byte count of data.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
