On 12/15/20 7:51 AM, Bob Liu wrote:
Hi Folks,
On 12/12/20 12:56 AM, Hannes Reinecke wrote:
On 12/11/20 5:33 PM, Jens Axboe wrote:
On 12/11/20 9:30 AM, Mike Snitzer wrote:
While I still think there needs to be a proper _upstream_ consumer of
blk_interposer as a condition of it going in.. I'll
The pull request you sent on Mon, 14 Dec 2020 12:47:57 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> tags/for-5.11/revert-problem-v5.10-raid-changes
has been merged into torvalds/linux.git:
On Mon, 2020-12-14 at 11:19 +0100, Christophe Varoqui wrote:
> Thank you for the review, the commit is in.
>
> the user reporting this, seems to face exactly the problem mentioned
> in 7db0c44 :
>
> commit 7db0c4466c0e5ed2179710f93d1d14a0bf92922a
> ...
> And the default timeout should be
Hi Linus,
The following changes since commit 2c85ebc57b3e1817b6ce1a6b703928e113a90442:
Linux 5.10 (2020-12-13 14:41:30 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
tags/for-5.11/revert-problem-v5.10-raid-changes
On 12/14/20 9:26 AM, Mike Snitzer wrote:
> On Mon, Dec 14 2020 at 11:02am -0500,
> Mike Snitzer wrote:
>
>> On Mon, Dec 14 2020 at 12:52am -0500,
>> Greg KH wrote:
>>
>>> On Mon, Dec 14, 2020 at 12:31:47AM -0500, Dave Jones wrote:
On Sun, Dec 13, 2020 at 03:03:29PM -0800, Linus Torvalds
On Mon, Dec 14 2020 at 11:02am -0500,
Mike Snitzer wrote:
> On Mon, Dec 14 2020 at 12:52am -0500,
> Greg KH wrote:
>
> > On Mon, Dec 14, 2020 at 12:31:47AM -0500, Dave Jones wrote:
> > > On Sun, Dec 13, 2020 at 03:03:29PM -0800, Linus Torvalds wrote:
> > > > Ok, here it is - 5.10 is tagged
On Mon, 2020-12-14 at 08:56 +0100, Christophe Varoqui wrote:
> Hello,
>
> a user brought to my attention "multipathd show config | grep
> usock_timeout" does not agree with the default value stated in the
> manpage : 4000 instead of 1000.
>
> And indeed,
>
> ./libmpathcmd/mpath_cmd.h:#define
On 2020-12-12 10:02:48, Tushar Sugandhi wrote:
> System administrators should be able to limit which kernel subsystems
> they want to measure the critical data for. To enable that, an IMA policy
> condition to choose specific kernel subsystems is needed. This policy
> condition would constrain the
On 2020-12-11 15:58:02, Tushar Sugandhi wrote:
> IMA provides capabilities to measure file data, and in-memory buffer
> data. However, various data structures, policies, and states
> stored in kernel memory also impact the integrity of the system.
> Several kernel subsystems contain such integrity
On Fri, Dec 11, 2020 at 9:56 PM Johannes Thumshirn
wrote:
>
> On 11/12/2020 15:57, SelvaKumar S wrote:
> [...]
> > +int blk_copy_emulate(struct block_device *bdev, struct blk_copy_payload
> > *payload,
> > + gfp_t gfp_mask)
> > +{
> > + struct request_queue *q =
On 2020-12-11 17:17:22, Tushar Sugandhi wrote:
>
>
> On 2020-12-11 4:25 p.m., Tyler Hicks wrote:
> > On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
> > > A new IMA policy rule is needed for the IMA hook
> > > ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> > >
> Probably the other people are right that making scopes shorter is more
> important when the function is very long.
How much will sizes of function implementations influence the acceptance
for possible source code refactorings?
https://refactoring.com/catalog/reduceScopeOfVariable.html
* Would
On 2020-12-11 15:58:01, Tushar Sugandhi wrote:
> The original IMA buffer data measurement sizes were small (e.g. boot
> command line), but the new buffer data measurement use cases have data
> sizes that are a lot larger. Just as IMA measures the file data hash,
> not the file data, IMA should
On 2020-12-11 15:58:07, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian
>
> SELinux stores the active policy in memory, so the changes to this data
> at runtime would have an impact on the security guarantees provided
> by SELinux. Measuring in-memory SELinux policy through IMA subsystem
On 2020-12-11 15:58:00, Tushar Sugandhi wrote:
> IMA functions such as ima_match_keyring(), process_buffer_measurement(),
> ima_match_policy() etc. handle data specific to keyrings. Currently,
> these constructs are not generic to handle any func specific data.
> This makes it harder to extend
On Fri, Dec 11, 2020 at 11:35 PM Keith Busch wrote:
>
> On Fri, Dec 11, 2020 at 07:21:38PM +0530, SelvaKumar S wrote:
> > +int blk_copy_emulate(struct block_device *bdev, struct blk_copy_payload
> > *payload,
> > + gfp_t gfp_mask)
> > +{
> > + struct request_queue *q =
On 2020-12-12 10:02:47, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows
On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows
This patchset tries to add support for TP4065a ("Simple Copy Command"),
v2020.05.04 ("Ratified")
The Specification can be found in following link.
https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs-1.zip
This is an RFC. Looking forward for any feedbacks or other alternate
On 12/11/20 7:41 AM, Tyler Hicks wrote:
On 2020-12-11 09:36:30, Tyler Hicks wrote:
The calls to pr_err() in this aren't quite following the style of the
other error SELinux error messages.
Sorry, I left out a word. I meant to say that the calls to pr_err() in
this *file* aren't quite
On Fri, Dec 11, 2020 at 07:21:38PM +0530, SelvaKumar S wrote:
> +int blk_copy_emulate(struct block_device *bdev, struct blk_copy_payload
> *payload,
> + gfp_t gfp_mask)
> +{
> + struct request_queue *q = bdev_get_queue(bdev);
> + struct bio *bio;
> + void *buf = NULL;
> +
On 12/11/20 4:32 PM, Tyler Hicks wrote:
On 2020-12-11 15:58:07, Tushar Sugandhi wrote:
From: Lakshmi Ramasubramanian
SELinux stores the active policy in memory, so the changes to this data
at runtime would have an impact on the security guarantees provided
by SELinux. Measuring in-memory
Add support for TP 4065a ("Simple Copy Command"), v2020.05.04
("Ratified")
The implementation uses the payload passed from the block layer
to form simple copy command. Set the device copy limits to queue
limits.
Signed-off-by: SelvaKumar S
Signed-off-by: Kanchan Joshi
Signed-off-by: Nitesh
On 2020-12-11 09:36:30, Tyler Hicks wrote:
> The calls to pr_err() in this aren't quite following the style of the
> other error SELinux error messages.
Sorry, I left out a word. I meant to say that the calls to pr_err() in
this *file* aren't quite following the right style. Please adjust all of
On 2020-12-09 11:42:12, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian
>
> IMA measures files and buffer data such as keys, command line arguments
> passed to the kernel on kexec system call, etc. While these measurements
> enable monitoring and validating the integrity of the system, it
Add new BLKCOPY ioctl that offloads copying of multiple sources
to a destination to the device. Accept copy_ranges that contains
destination, no of sources and pointer to the array of source
ranges. Each range_entry contains start and length of source
ranges (in bytes).
Introduce REQ_OP_COPY, a
Thank you for the review, the commit is in.
the user reporting this, seems to face exactly the problem mentioned in
7db0c44 :
commit 7db0c4466c0e5ed2179710f93d1d14a0bf92922a
...
And the default timeout should be increased to 4 seconds to ensure
multipath runs correctly on large
Hello,
a user brought to my attention "multipathd show config | grep
usock_timeout" does not agree with the default value stated in the manpage
: 4000 instead of 1000.
And indeed,
./libmpathcmd/mpath_cmd.h:#define DEFAULT_REPLY_TIMEOUT 4000
Can you confirm this change is valid ?
diff --git
28 matches
Mail list logo
